[concurrency-interest] CompletableFuture.whenComplete survey
Doug Lea
dl at cs.oswego.edu
Sat Dec 19 09:15:18 EST 2015
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".
More information about the Concurrency-interest
mailing list