RFE to change try-with-resources

[John Rose]

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”.

Another way to skirt the mind-reading game is to add small annotations 
which would change the behavior from the main meaning of the code to 
some (hopefully popular) secondary variant meaning.  In the case of TWR 
I mean some simple declarative notation to add to a TWR statement that 
would guide close-errors correctly atop body-exceptions.  (Can you do 
this today?  Don’t know; don’t care ATM, and it’s probably not 
worth the complexity.)  Another example would be legacy non-total switch 
statements, which unfortunately fail to read the minds of programmers 
who intend them to be total; again, you can’t just change the language 
to read everyone’s mind differently, but you could add some tweaky 
annotation.  This would be a different slippery slope, though:  The 
extra tweaky annotations are usually not worth the language complexity 
they add.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220218/43681fa4/attachment.htm>