RFR: jsr166 jdk9 integration wave 2

[Martin Buchholz]

Very sorry to muddy the waters after call for votes has gone out, but
I thought of another course of action:
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".


On Wed, Dec 16, 2015 at 12:48 PM, Martin Buchholz <martinrb at google.com> wrote:
> One more point - In try-with-resources it's clear that the try body is
> the "main event" while the auto-generated calls to close are intended
> to be "cleanup", so it's natural that the try body exception wins.
> With whenComplete:
> - it's less obvious that the whenComplete action is unimportant
> - both CompletionStages may remain accessible so the risk of losing
> the source exception is lower, and preserving the integrity of the
> source exception is more valuable.