RFR: jsr166 jdk9 integration wave 2

[Timo Kinnunen]

Hi, 

Following the single-threaded try-with-resources semantics very closely might not give the most useful result because there is at least one aspect that’s fundamentally different between these cases. That is, in the case where the “try”-stage (or block) completes normally but the “finally”-stage completes abruptly, in the CompletableFuture version “completes normally” has an extralinguistic representation that continues to exists until it is garbage collected. It seems terribly wasteful to just throw that away and overwrite or ignore it if the “finally”-stage completes abruptly.

Given the previous, modeling “completes normally” and “completes abruptly” both as exceptional completions in CompletableFuture would match the reality more closely. In both cases a container for the result will be present, which can be viewed as analogous to a Throwable in the single-threaded case.

Then, it is in the completion stage results container where the suppressing and cloning should happen, and not in the Throwables contained in it.



Sent from Mail for Windows 10



From: Martin Buchholz
Sent: Thursday, December 3, 2015 01:51
To: Peter Levart
Cc: core-libs-dev
Subject: Re: RFR: jsr166 jdk9 integration wave 2


We're stuck.  Peter wants to make Throwables cloneable, I want to
reverse the order of throwables and add the past Throwable as a
suppressed exception to the exception of a dependent action, and Doug
wants the current webrev behavior of adding the dependent action as a
suppressed exception of the source.

I'm willing to accept the small incompatibility of throwing a
different exception when everything fails; the existing spec doesn't
promise what happens in this case.