On 19/12/2025 19:31, Attila Kelemen wrote:
:
1. `InterruptedException`: I do think that thread interrupts are a
poor way to manage cancellation. The fact that they are checked is a
nightmare, because effectively almost all APIs should prepare for the
fact that whatever they do might do something longer, and must be
cancelled which would imply that all methods should declare
`InterruptedException` (which is of course absurd). Even if STS
doesn't pick up the job to bring sane cancellation into the JDK, it
should wrap cancellation into a new unchecked exception like
`OperationCancelledException` (or something like that). This would not
be important, because if later Java decides to introduce better
cancellation, then a checked exception will be practically impossible
to remove from an API, while an unchecked one could be retrofitted to
extend a new one.
A small set of methods can detect/respond to a request to stop/cancel
their current activity. Many of these declare that they throw the
special InterruptedException for this purpose. There are a few other
methods, esp. in the I/O area, that respond to the request by returning
early or throwing a different exception.
InterruptedException is special, making it unchecked would make it more
hazardous than it is already. This is because throwing
InterruptedException clears the interrupted status. If you catch the
exception then you must remember to reset the interrupted status when
continuing without re-throwing the exception. This ensures that code
that executes subsequently can also respond to the request to finish up.
As regards introducing a different/better cancellation mechanism then
this project has spent consideration time on this topic. The early
exploration phase of this project prototyped a higher level cancellation
mechanism, and a mapping to the low-level interrupt mechanism. The
conclusion from exploration into several different directions is that it
just wasn't worth it, and would be too confusing for developers to have
two mechanisms.
As regards STS.join throwing InterruptedException then it shouldn't be a
surprise. The other APIs in this area do the same. We know
InterruptedException and the interrupted status are hard to use. There
are some ideas for making the existing thread interruption mechanism
easier to use but nothing close to a proposal/JEP at this time.
-Alan
