My 2c,
As an interrupt can come from anywhere, not necessarily from the
caller/consumer—if you react to interruption by either throwing a new
Exception, or wrap an InterruptedException, then the knowledge that the
situation was caused by an interrupt is lost. Lost information tends to
be a bad thing unless one is sure that no one will ever need that
information.
On 2025-11-07 09:23, [email protected] wrote:
----- Original Message -----
From: "Alan Bateman" <[email protected]>
To: "Remi Forax" <[email protected]>, "Pavel Rappo" <[email protected]>
Cc: "core-libs-dev" <[email protected]>
Sent: Thursday, November 6, 2025 10:37:13 AM
Subject: Re: On throwing InterruptedException
On 05/11/2025 14:00, Remi Forax wrote:
:
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).
Rethrowing the InterruptedException is okay. Throwing a new exception
that is not an InterruptedException is okay too but only after restoring
the interrupted status, otherwise the thread might block again is some
catch block as it unwinds.
and I disagree here :)
Let's take a step back, in Java code
1/ people are writing many catch blocks that they should not and usually the
code in the catch block is not exercised enough so it is a little brittle.
2/ the normal behavior is to either get an InterruptedException or to have the flag
"interrupted" set, but not both.
If you throw an exception AND set the flag, usually the code in a catch block
will behave weirdly because the catch code has not be written with that corner
case in mind.
Throwing an unrecoverable error usually avoid that problem (and yes, i'm aware
it may clash with the way old executors work but virtual threads are our
saviors).
-Alan
regards,
Rémi
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
