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.
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(). 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 <[email protected]> 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 >
