CompletionStage

[Sam Pullara]

On Sun, Jun 30, 2013 at 1:34 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> As I was converting a test I had written for my Promises, there seems to
>> be a
>> missing method. It appears that both handle() and exceptionally() force
>> the
>> Future to then succeed.
>>
>
> 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.


>
>
>> I was also somewhat surprised to find that my RuntimeExceptions were being
>> wrapped in CompletionException when they are passed to handle() and
>> exceptionally().
>>
>
> Right. This is sometimes a little annoying but it is also
> among the few conventions that mesh with Future method specs.
> At least the spec tells you clearly that this happens.
>

* <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?


>  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 the pattern is to listen to your own CompletableFuture and
watch for CancellationExceptions? Again that is weird that I can't act on
them without rethrowing them. Please consider adding something akin to
onFailure and ensure.

Sam


>
>
> -Doug
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130630/35a977ac/attachment.html