CompletionStage

[Doug Lea]

On 06/30/13 17:00, Sam Pullara wrote:
>
>     They can (re)throw any exception they like when completed exceptionally.
>     Which I think gives you the effects you wanted in next few parags of
>     your mail?
>
>
> This is really ugly. How many wrapping layers might I end up with? I can't just
> throw the throwable. This is a very common pattern, much more common than
> rescue() semantics. Very rarely on failure do you want to set the result value.
>

This is a good point. When the stage methods were part of
CompletableFuture, it was too easy and cheap to bother:
just call completeExceptionally in the function body.
But maybe there should be some way to get the same effect
using a stage method.

> * <p>Upon exceptional completion (including cancellation), or when a
>   * completion entails an additional computation which terminates
>   * abruptly with an (unchecked) exception or error, then all of their
>   * dependent completions (and their dependents in turn) generally act
>   * as {@code completeExceptionally} with a {@link CompletionException}
>   * holding that exception as its cause.  However, the {@link
>   * #exceptionally exceptionally} and {@link #handle handle}
>   * completions <em>are</em> able to handle exceptional completions of
>   * the CompletableFutures they depend on.
>
> Why doesn't exceptionally and handle have a CompletionException as the type
> rather than Throwable if this is the case?

Because of that "generally" disclaimer. You can get out-of-band
exceptions like OOME that occur while processing the stage itself.
I do agree that it is annoying. I don't think there's a solution
to the annoyingness.


>
>         For cancellation, it doesn't look like there is any way to get the message
>         downstream. In promises, cancellations go the opposite direction to
>         exceptions
>         which means you can react to them. In CompletionFuture it appears that they
>         don't propagate down to the child CompletableFutures
>
>
>     Yes, they do (unless an intervening handle/exceptionally.)
>
>
> The children will fail with the same exception, but I don't see where they are
> proactively notified that they are cancelled and should stop work. Hmmm, unless

Do you mean, that we should try to cancel ongoing asyncs?
For the usual reasons, the best we can guarantee is to not run
them if they are triggered but haven't started yet. If you want
to do more, you have to do it yourself, for example, have some
shared atomic sentinel that they can read. (This is the same
issue that j.u.c has disappointed you about in the past, and
Brian has disappointed you about in Streams. It's not that we
don't like you(!), but no one knows of a reasonable general purpose
solution to this, and are coming to believe that nothing will ever
be better than relying on smart developers to roll their own
special-purpose solutions.)

-Doug