On 17/11/2025 00:34, David Holmes wrote:
On 6/11/2025 7:37 pm, Alan Bateman wrote:
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.
Library code is unlikely to "know" the full context of its usage. If
library code is handling IE by throwing some other exception then I
think the advice has to be restore the interrupted status before
throwing, otherwise some other part of the system, including code
further up in the call chain, may block/hang. Yes, there will be a few
cases that are more advanced or have more global knowledge, but you get
into difficult coordination issues once you try to reduce the scope of
the handling.
-Alan
