[concurrency-interest] CompletableFuture.whenComplete survey

Vladimir Ozerov ppozerov at gmail.com
Sat Dec 19 15:48:03 EST 2015

2015-12-19 22:41 GMT+03:00 Chris Purcell <chris.purcell.39 at gmail.com>:
> Behaving like handle() makes sense, but wasn't strictly speaking one of
> the survey options. Will you (a) open a new survey, (b) throw
> B-with-A-suppressed (survey option 2), or (c) throw B (like handle)? I'd
> vote for C.

+ 1 for just throwing B without A suppressed.

When I receive normal result X and then transform it to Y inside my *new*
completion stage, it doesn't mean that I "suppressed" X. Likewise, throwing
an exception from a new completion stage should not mean that I suppressed
previous exception. Instead, most likely it means that user *processed*
previous exception and transformed it into some other form.

try-with-resources is not very good analogy here, because it has a single
control flow. If the first exception is thrown from try-block and then the
control flow is disturbed by the second exception from close() method, we
end up with two pending unrelated exceptions. Both of them must be
propagated further somehow and this is where suppression comes into play.
To the contrast, "whenComplete" and "invoke" create new control flow. And
as there is no ambiguity, it is not clear why A should be suppressed. Looks
like we can simply forget about it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151219/ad93df65/attachment.html>

More information about the Concurrency-interest mailing list