Rethinking Exceptions in the Context of Loom and Structured Concurrency

[Eric Kolotyluk]

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/20251218/f54f8f47/attachment.htm>