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 <[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
