Rethinking Exceptions in the Context of Loom and Structured Concurrency

[Alex Otenko]

I think the answer will depend on what you write.

If you keep re-throwing exceptions, you wish it was a return value.

If you keep checking the return value to make sure you clean up resources,
unlock the locks, invoke the same routine, you wish you had
try-with-resources or try/catch/finally.

If you write map/reduce, you wish you could supply the monoid for errors
just like for values.

There are horror stories for all of these cases.

On Fri, 19 Dec 2025, 04:55 Eric Kolotyluk, <eric at kolotyluk.net> wrote:

> Hi all,
>
> I’m starting a new thread to continue a discussion that emerged elsewhere,
> per mailing list etiquette, and to give the topic a clean and traceable
> home.
>
> My interest here isn’t reactive to any one exchange. I’ve been
> experimenting with Loom since its early iterations, and over time it has
> sharpened a concern I already had: whether Java’s traditional exception
> model remains the right default abstraction in a world of structured
> concurrency, virtual threads, and large-scale composition.
>
> To be clear, this is not a claim that “exceptions are broken” or that Java
> should abandon them. Java’s exception system has supported billions of
> lines of successful code, and I’ve used it productively for decades.
> Rather, Loom makes certain trade-offs more visible — particularly around
> control flow, cancellation, failure propagation, and reasoning about
> lifetimes — that were easier to ignore in a purely thread-per-task world.
>
> The core questions I’m interested in exploring are along these lines:
>
>    - How do unchecked exceptions interact with structured concurrency’s
>    goal of making lifetimes and failure scopes explicit?
>    - Do exceptions remain the best abstraction for expected failure in
>    highly concurrent, compositional code?
>    - Are there patterns (or emerging idioms) that Loom encourages which
>    mitigate long-standing concerns with exceptions — or does Loom expose new
>    ones?
>    - More broadly, should Java be thinking in terms of additional
>    failure-handling tools rather than a single dominant model?
>
> I’m not advocating a specific alternative here — just inviting a technical
> discussion about whether Loom changes how we should think about error
> handling, and if so, how.
>
> That said, exposure to other ecosystems (e.g., Scala, Kotlin, and more
> recently Rust) has broadened how I think about failure modeling. One thing
> I’ve consistently appreciated about Java is that it tends to integrate
> external ideas deliberately, rather than reflexively rejecting them or
> adopting them wholesale. Loom itself is a good example of that approach.
>
> I’m interested in whether error handling deserves a similar re-examination
> in light of Loom’s goals.
>
> Looking forward to the discussion.
>
> Cheers,
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20251219/84000138/attachment.htm>