On throwing InterruptedException

[Pavel Rappo]

And also this, which is a bit contrived but valid nonetheless:

    } catch (InterruptedException e) { // good
        throw new InterruptedException();

    }


On Wed, Nov 5, 2025 at 3:38 PM Pavel Rappo <pavel.rappo at gmail.com> wrote:
>
> Oops, forgot to add one more:
>
>     } catch (InterruptedException e) { // good
>         throw e;
>     }
>
> On Wed, Nov 5, 2025 at 3:36 PM Pavel Rappo <pavel.rappo at gmail.com> wrote:
> >
> > I'm not sure that's what Alan said. Unless stated otherwise, re-throw
> > an exception `e` means `throw e`, so that `e` is the outermost,
> > unwrapped exception. Also you didn't say anything about "interrupted
> > status". But maybe, it's better to let Alan clarify what he meant.
> >
> > For the sake of greater clarity, let me provide a few examples of
> > handling InterruptedException, and label them "good" or "bad" as per
> > my own understanding. In this examples I assume that code in question
> > does _not_ control or know what's on the stack above it:
> >
> >     } catch (InterruptedException e) { // good
> >         Thread.currentThread().interrupt();
> >         return;
> >     }
> >
> >     } catch (InterruptedException e) { // bad
> >         return;
> >     }
> >
> >     } catch (InterruptedException e) { // good
> >         Thread.currentThread().interrupt();
> >         throw new IOException();
> >     }
> >
> >     } catch (InterruptedException e) { // bad
> >         throw new IOException();
> >     }
> >
> >     } catch (InterruptedException e) { // bad
> >         throw new IOException(e);
> >     }
> >
> >     } catch (InterruptedException e) { // probably avoid as confusing
> >         Thread.currentThread().interrupt();
> >         throw new IOException(e);
> >     }
> >
> > Specifically:
> >
> >     } catch (InterruptedException e) { // bad
> >         throw new IOError();
> >     }
> >
> >     } catch (InterruptedException e) { // bad
> >         throw new IOError(e);
> >     }
> >
> > -Pavel
> >
> >
> > -Pavel
> >
> > On Wed, Nov 5, 2025 at 2:00 PM Remi Forax <forax at univ-mlv.fr> wrote:
> > >
> > > ----- Original Message -----
> > > > From: "Pavel Rappo" <pavel.rappo at gmail.com>
> > > > To: "core-libs-dev" <core-libs-dev at openjdk.org>
> > > > Sent: Wednesday, November 5, 2025 12:10:11 PM
> > > > Subject: On throwing InterruptedException
> > >
> > > > I've seen code that wraps InterruptedException in some other exception
> > > > prior to throwing that other exception; for example:
> > > >
> > > >    catch (InterruptedException e) {
> > > >        throw new IOException(e);
> > > >    }
> > > >
> > > > I wonder if there are any legitimate cases for this, because I cannot
> > > > think of any. In my mind, it's always InterruptedException itself that
> > > > should be thrown; and if it cannot be done, then the interrupted
> > > > status should be set.
> > > >
> > > > This is because if code that catches exceptions expects
> > > > InterruptedException, it expects to catch it directly rather than
> > > > search the exception graph (i.e. cause/suppressed) of the caught
> > > > exception for InterruptedException.
> > >
> > > It depends on whether you have faith in your fellow developers :)
> > >
> > > If a thread is interrupted, it should stop ASAP.
> > > So if you catch InterruptedException and rethrow a new exception, this should be okay (as Alan said).
> > >
> > > But in practice, it may be a bad idea because people tend to write code that catch exceptions and do nothing,
> > > so throwing an IOError is usually safer.
> > >
> > > >
> > > > -Pavel
> > >
> > > regards,
> > > Rémi