Concurrency and Exceptions

[Alan Bateman]

On 30/11/2021 16:36, Eric Kolotyluk wrote:
> In my documentation I want to make the statement
>
> In concurrent frameworks, it was not safe to throw Exceptions because the
>> JVM could not manage this.
>>
> My sense is that Project Loom addresses this and fixes it somewhat, but I
> don't want to miss-state the problem Loom attempts to solve.
>
> *Is it the JVM, or simply the Java Language/Libraries that could not
> support safe Exception Handling in Concurrent scenarios?*
>
> Up until now, this led to a Functional approach of returning composite
> results, such as Scala Option, Either, Try, etc. to avoid throwing
> Exceptions.
>
> I understand that in Kotlin Coroutines, it is safe to throw/catch
> exceptions in concurrent code, but I have never really tried this.
>
I think it would be a bit misleading to say "the JVM could not manage this".

Our focus on exceptions is to make it easier to collect, process, 
select, and propagate. When a task splits into N tasks then sometimes an 
exception is fatal and all remaining tasks can be cancelled to avoid 
waiting for them to complete. In other cases, there will be some 
tolerance for exceptions. The idea is that you can implement the policy 
as a completion handler.

We've tried to avoid introducing any new discriminated union, instead we 
are using Future objects to represent a result or exception. The 
completion handler that implements the policy for exceptions can define 
an API to make it easy to access the results or exceptions. The handler 
implementation will need to deal with concurrency but it can define 
something much simpler for the (typically main) task to use.

-Alan