[concurrency-interest] CompletableFuture.whenComplete survey
dl at cs.oswego.edu
Sat Dec 19 12:54:15 EST 2015
On 12/19/2015 11:16 AM, Chris Purcell wrote:
> 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).
Actually, at the moment, our jsr166 version suppresses B.
Nothing has changed in our codebase since the a.addSuppressed(b)
fix. We were about this to commit to OpenJDK when further questions emerged,
leading to survey. My plans were to check for any new ideas or
over-my-dead-body reactions stemming from survey before changing.
Also, to recap related core-libs-dev discussions: The initial suggestion
to serialize or clone A doesn't work well with some user Throwable
classes. So reflection-based pseudo-cloning should be treated as
a desperation move, avoided when there are other options.
It was also pointed out that with a.addSuppressed(b), the call
might occur while exception a is being processed in another thread.
Which might be surprising, but is thread-safe and not in itself
a compelling reason not to do it.
> WhenComplete seems like the only way to reliably close resources in async code,
This was among initial motivations (see list archives mainly in December 2012).
But as it turns out from survey, a lot of people expect or want it to
behave more like handle(). Which is a different issue than the one
you first raised.
More information about the Concurrency-interest