Concurrency and Exceptions

[Eric Kolotyluk]

@Alan Bateman <Alan.Bateman at oracle.com>


> I think it would be a bit misleading to say "the JVM could not manage
> this".
>

Fair enough, what would be more accurate to say? "The legacy Java
Concurrency Framework did not deal with Exceptions *as completely*..." I am
trying to define the problems around Exceptions that Loom solves.

Yes, in JDK 17 there is no way to find out the cause of a Future failing,
and in JDK 18 we have state(), resultNow(), and exceptionNow() to make
Exception handling *more complete*. Completion Handlers allow the
implementation of broad policies on failure/success handling.

Will it be okay to pass a StructuredExecutor instance to CompletableFuture
CompletionStage? I imagine this could be unsafe if we pass a
CompletableFuture outside the ScopeLocal of the Thread Tree, but then
passing the Future out would be just as unsafe.

There is so much nuance going on here, or maybe I am just perceiving it
that way...

Cheers, Eric


On Tue, Nov 30, 2021 at 1:03 PM Paul Bjorkstrand <paul.bjorkstrand at gmail.com>
wrote:

>
>
>> 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.
>>
>
> I think this was something I was missing in my original understanding,
> thank you for this nugget! I believe treating CompletionHandlers as the
> means to _provide_ the results/failures, rather than just _track_ them
> makes a lot of sense.
>
> Would you say that the intent of CompletionHandler is to negate, to some
> degree, the need to individually call Future.[result|exception]Now()
> (outside the handler, that is)? That is what it sounds like to me, and it
> makes a CompletionHandler's purpose a lot more useful than just "short
> circuit other tasks on the first success/failure".
>
>
> -Paul
>