Rethinking Exceptions in the Context of Loom and Structured Concurrency

[Alan Bateman]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20251224/7f16eb8d/attachment.htm>