Rethinking Exceptions in the Context of Loom and Structured Concurrency

[David Alayachew]

Hello @Eric Kolotyluk <eric at kolotyluk.net>,

Let me start off by giving context -- the way STS uses exceptions is a
little more complicated than just "throw, even on very much expected
errors".

One of the downsides of STS is that it is the hotelier to several different
guests with very different (almost orthogonal) semantic needs -- thus
forcing the final design to sardine them together in some uncomfortable
ways.

You mentioned one of these pain points in the previous thread -- about the
joiner returning null when successful, and exception otherwise.

Stuff like that is usually an indicator that an API is trying to do 2 or
more things at once, and can't easily accomodate both in the cleanest way.
The literal reason java.lang.Void was created back when was to bandaid this
exact problem.

So, understanding that STS is trying to cover multiple different API needs
in one hood, hopefully that makes more sense why the answer is null vs
exception for that particular joiner. It's not clean, but it serves the
purpose well enough, imo.

With that context out of the way, let me respond to your points.

   - How do unchecked exceptions interact with structured concurrency’s
   goal of making lifetimes and failure scopes explicit?

I'm not sure I follow. Are you asking how unchecked exceptions thrown by MY
CLIENT CODE interact with STS? If so, I'd say, the same as everywhere else.

My understanding is that Unchecked is for programming bugs, and therefore,
should not be dealt with. The only difference between other contexts and
STS is that, for some of the joiners (awaitAll), STS gives you the choice
to do that or not. It's not necessarily the default to propagate, which
some developers have raised disagreement with in the past.

   - Do exceptions remain the best abstraction for expected failure in
   highly concurrent, compositional code?

Well, again, it depends what you mean here. This question and the one
before it are rather open-ended.

Currently, the join method throws several different exceptions.

WrongThreadException -- I think using an (unchecked) exception is the right
choice here because this situation can only occur via programming error.

IllegalStateException -- Same logic as above.

FailedException -- Some feel this should be replaced by a return type in
the vein of Result<T> or something related. I don't necessarily agree, as I
still do want a stack trace with line numbers. And if that Result<T> is
actually Result<T,Ex> where Ex is an exception, well I think Exceptions are
the better vehicle for that type of response instead of Result.

TimeoutException -- This is a great example of what I mean when I say
sardine. Normally, this would obviously be a checked exception (an expected
failure that no amount of prep time can realistically prevent), but since I
can turn off timeouts, forcing everyone to pay for this doesn't make sense.
Aka, sardines. But really, the original sin is that code that doesn't do
timeouts shouldn't be able to throw this. Sadly, the only real way to do
this in Java 25 is by significantly bloating the Java api. You'd have to
break apart and duplicate the API in ways that increase the surface area
while adding very little semantic meaning. That's a double whammy in the
worst way. That'd be like Stream vs IntStream vs DoubleStream all over
again. I can definitely understand ehy they do not want that for STS. Maybe
some exploration is being done towards remedying this, idk.

InterruptedException -- Well, this one is fine. However you feel about
Interrupts and how Java implements them, STS is advertised to handle and
emit interrupts "properly", therefore the behaviour here is unavoidable,
according to the spec. You'd have to trandform STS into something wildly
different in order to change how or if we deal in InterruptedExceptions.

So, from what I can see here, each of the exceptions seem reasonable.
Albeit, some are the result of conflicting concerns. But I don't see how
any other solution would address these better.

   - 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 think Java already has, but even in light of that exploration, chose to
use exceptions here.

But frankly, both of these points are broad. I think you need to be more
specific here.

I will say, your original post in the previous thread was asking a very
different question than this thread. Did you mean to, or are you building
up to that?


On Fri, Dec 19, 2025, 8:25 AM David Alayachew <davidalayachew at gmail.com>
wrote:

> 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/45f5a9f9/attachment.htm>