On throwing InterruptedException

[David Holmes]

On 17/11/2025 12:32 pm, Pavel Rappo wrote:
> David, I'm not entirely sure what you are referring to, but it sounds
> like an atypical case to which general guidelines do not apply.

It is just about making cancellation semantics a part of the API. 
Interrupt is just the mechanism to aid in implementing cancellation.

> If a FutureTask is cancelled, by interruption or otherwise, a call to
> get() will throw CancellationException. If interruption occurs, it is
> an implementation detail, and it is confined to the thread that is
> executing the task. Such interruption has no bearing on a thread that
> calls get().

Okay but that is just due to the async nature of FutureTask. Imagine 
instead a ServiceObject with methods to have a service performed, and a 
method to shutdown the service. The service methods are synchronous and 
throw ShutdownException if the service gets shutdown whilst the request 
is in progress. Interruption is just an available mechanism to aid in 
that and it may not be appropriate to leave the interrupt state set 
after the service method returns. Of course we have to look at the 
broader context in case there could be multiple levels of cancellation 
that apply - as Doug says in CPJ you can't necessarily distinguish 
whether an interruption means cancel the current task, or terminate the 
current thread. You need complete context to know what to do.

David
> If a thread executing the task is interrupted directly, then get()
> will throw ExecutionException that wraps InterruptedException. This is
> quite an unusual situation, as no one should interrupt the thread
> except for its owner.
> 
> 
> -Pavel
> 
> On Mon, Nov 17, 2025 at 12:34 AM David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 6/11/2025 7:37 pm, Alan Bateman wrote:
>>> 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.
>>
>> I would qualify the "restoring the interrupted status" part as it all
>> depends on the overall context. If converting the IE to some other
>> exception is part of the cancellation behaviour for this API then it may
>> not be necessary to restore the interrupted status because the user of
>> the API already knows this aspect of the computation has been cancelled.
>> That cancellation request (the interrupt) may not apply to anything
>> higher in the call-chain. Which is IIRC exactly how FutureTask
>> cancellation operates.
>>
>> David
>>> -Alan
>>