Rethinking Exceptions in the Context of Loom and Structured Concurrency

[Alan Bateman]

On 19/12/2025 19:31, Attila Kelemen wrote:
> :
>
> 3. `State.UNAVAILABLE`: Maybe a bit off-topic, but let me put it here: 
> It is kinda evil in my opinion, because most of the time I would fetch 
> the result after a `join` where that is an impossibility, yet its 
> presence makes switch expressions awkward. It would be nice to have a 
> `ResultState` with only two states `SUCCESS` or `FAILED`. Then of 
> course, the old `State` is not necessary, because it could become just 
> a `boolean isAvailable()` instead.
>

Cancellation and short circuiting means the scope may be cancelled 
during the "forking phase" or while subtasks are running. There may even 
be a few stragglers that are slow to respond to the request to finish 
and continue concurrently with the code that executes after join. So 
several cases where is no result or exception. Mapping "did not run", 
"cancelled" and other states to FAILED is problematic, as is introducing 
further states.

(If I read your example correctly then it just wants to cancel when any 
subtask fails but it doesn't want the scope (or join) to fail. In that 
case, `Joiner.allUntil(s -> s.state() == Subtask.State.FAILED)` should 
reduce it down. No need to keep a reference to the subtasks, no need for 
the results list, and the handling of FailException goes away to). The 
result from join will be the list of subtasks that can be filtered to 
exclude the UNAVAILABLE then partitioned into the success + failed buckets.)

-Alan.