[concurrency-interest] CompletableFuture.whenComplete survey

Chris Purcell chris.purcell.39 at gmail.com
Sat Dec 19 11:16:04 EST 2015


The second option surprised me, as we now have a fourth approach to
suppressed exceptions in Java: try/finally (throw away A),
try-with-resources (suppress B), j8 whenComplete (throw away B) and j9+
whenComplete (suppress A). Isn't this unnecessarily complicated? Why not
behave like a finally block, and let the user add A as a suppressed
exception if they want it?

WhenComplete seems like the only way to reliably close resources in async
code, so I expected it to work like try-with-resources. That seems to be
the point of contention for others too. Perhaps there should be another
method for this use-case instead? One which takes a simple runnable and
suppresses any exception it throws.

Thanks!
Chris

On Sat, 19 Dec 2015 14:38 Doug Lea <dl at cs.oswego.edu> wrote:

> 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".
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151219/1ff42cc6/attachment.html>


More information about the Concurrency-interest mailing list