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 <[email protected]> wrote:
>
> ----- Original Message -----
> > From: "Pavel Rappo" <[email protected]>
> > To: "core-libs-dev" <[email protected]>
> > 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
