[concurrency-interest] CompletableFuture.whenComplete survey

[Doug Lea]

On 12/19/2015 08:40 AM, Joe Bowbeer wrote:
> I'm still holding out for option C: none of the above.  (Also I want access
> to the voter database!)

I set it up as anonymous.

> 2. The completion handler receiving exception1 may not want it to reach the
> next stage, even via getSuppressedExceptions.
>

In which case, why not use CF.handle to perform arbitrary outcome translation?

> 1. That exception1 is not "suppressed" because it has already been delivered
> to user code.

This always holds for a suppressed exception -- some code catches it
but then does addSuppressed. The term "suppressed" is not perfect here:
   "e1 with suppressed e2"
is treated in nearly the same way as
   "e2 with cause e1",
but with roles swapped.

Martin suggested (on core-libs-dev) an alternative that might reduce
confusion. Or might not. Thoughts welcome.

On 12/18/2015 02:08 PM, Martin Buchholz wrote:
> Instead of calling addSuppressed on the source exception, call
> addSuppressed on the wrapping CompletionException.  This has the
> upside that the integrity of both original exceptions is maintained,
> but the downside that the suppressed exception is likely to be
> discarded since the CompletionException is "just a wrapper".  In fact,
> get() will do that.  But we can modify reportGet to transfer any
> suppressed exceptions from the CompletionException to the
> ExecutionException, somewhat mitigating this problem, at the cost of a
> small tax on all users of get() who encounter abnormal completion.  As
> to which exception gets to be the cause and which the suppressed, I
> still think it makes sense for the action exception to be the cause
> and the source exception to be suppressed, by analogy with "finally".