Rethinking Exceptions in the Context of Loom and Structured Concurrency
Remi Forax
forax at univ-mlv.fr
Wed Dec 24 15:00:24 UTC 2025
> From: "attila kelemen85" <attila.kelemen85 at gmail.com>
> To: "Alan Bateman" <alan.bateman at oracle.com>
> Cc: "loom-dev" <loom-dev at openjdk.org>
> Sent: Wednesday, December 24, 2025 12:54:59 PM
> Subject: Re: Rethinking Exceptions in the Context of Loom and Structured
> Concurrency
>> 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.
> It would have been better if InterruptedException would be in its own unchecked
> hierarchy (i.e. not an `Exception`), but likely that would be too big of a
> breaking change now.
Yes,
and I believe this is true for all checked exceptions,
the default behavior of an exception should be to be propagated, but with the current type system, there are cases where you can not propagate a checked exception,
so either we improve the type system in a backward compatible way or we make all checked exceptions unchecked.
Weirdly, changing one exception from checked to unchecked is not backward compatible change but changing all checked exceptions to be unchecked is a backward compatible change.
> Attila
regards;
Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20251224/17df8d3e/attachment.htm>
More information about the loom-dev
mailing list