RFE to change try-with-resources

[Joe Darcy]

On 2/18/2022 2:41 PM, John Rose wrote:
>
> On 16 Feb 2022, at 10:33, Alex Buckley wrote:
>
>     This RFE is a good example of something that feels like a "small
>     tweak" to a much-loved feature, but would actually make the
>     feature harder to learn and use --
>     to say nothing of the compatibility impact of changing the feature
>     so long after its introduction (try-with-resources shipped in Java
>     7 after huge amounts of discussion).
>
> Good summary. This case is also an example of that other kind of 
> “small tweak” that turns out to be the first step down a slippery 
> slope, even if at first we thought it was a “one and done” incremental 
> improvement. The slope in this case is dealing with an amorphous cloud 
> of expectations about which throwables should take precedence over 
> which other throwables. Anything the language does (including 
> basically nothing, as today) is going to leave open disappointments 
> (from those with more definite expectations) that we didn’t go far 
> enough in defining the new priority/suppression order for exceptions. 
> The JBS entry doesn’t ask for a distinction between RuntimeExceptions 
> and other Exceptions, but the next one surely would. (And maybe 
> java.base throwables should be ordered differently from application 
> throwables?)
>
> Ultimately, requests like this for finely-graded distinctions like 
> this tend to be proxies for the basic complaint of, “why doesn’t javac 
> just read my mind”? If such a complaint is dressed up as a plausible 
> incremental tweak like the JBS entry in question here, then we might 
> fall for it, but afterwards we will still be hearing users say, “hey 
> wait, /that/ didn’t really read my mind, so here’s /another/ RFE”.
>
> The best way to stay out of the mind-reading game is to stick to 
> reasonably simple semantics, and say “that’s what we all get, let’s 
> make the best of it”.
>
FYI, there were voluminous discussions about try-with-resource (nee ARM 
-- automatic resource management) during Project Coin. The public 
discussions are archived at:

https://mail.openjdk.java.net/pipermail/coin-dev/

IIRC, during  the development phase of try-with-sources it was also 
suggested that more severe throwables should receive more prominent 
placement in the array of suppressed exceptions. It was also explicitly 
considered, and rejected, to have any special handling for the 
ThreadDeath error thrown  by the long-deprecated Thead.stop method.

The reasons these variants were rejected are aligned with the rationale 
put forward by Alex and John: having a predictable feature that is more 
straightforward to use was judged to be better than a more "clever" 
feature in error handling.

I find there is usually better leverage to spend effort on the 
common-path rather than making the error-handling more complicated.

As a retrospective investigation of the usage of try-with-resources, it 
would be interesting to see how often suppressed exception are checked 
at all.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220218/ccdef434/attachment-0001.htm>