Rethinking Exceptions in the Context of Loom and Structured Concurrency

[Davor Hrg]

I have also been experimenting with exceptions as values.

It served me well for some initial experiments with wrapping HTTP
fetch-like utilities.

One issue came up: It was fine while I was not interested in what exception
happens,
but as soon as I wanted to check multiple exception types I had to resort
to Throwable.

My exploration is still superficial, but I have not found a way to define
exception as value
where it can define  what "throws IoException,ValidationError" can. we
would maybe need union types. ...
and I am also afraid what happy when we start mixing the two concepts all
over the codebases.

This exploration of errors as types also made me appreciate Exceptions bit
more.







On Fri, Dec 19, 2025 at 7: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/96c2db3a/attachment-0001.htm>