Rethinking Exceptions in the Context of Loom and Structured Concurrency

[David Alayachew]

And just for context for all, here is the previous thread where this
discussion originated.

https://mail.openjdk.org/pipermail/loom-dev/2025-December/008117.html

You can start reading from there. A few more replies later, and then this
new thread was created, so as not to distract from the other topic.

On Fri, Dec 19, 2025, 1:35 AM 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/b215a970/attachment.htm>