On throwing InterruptedException

[Viktor Klang]

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, forax at univ-mlv.fr wrote:
> ----- Original Message -----
>> From: "Alan Bateman" <alan.bateman at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>, "Pavel Rappo" <pavel.rappo at gmail.com>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
>> 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