Proposal: Automatic Resource Management (original) (raw)

Reinier Zwitserloot reinier at zwitserloot.com
Mon Mar 9 16:27:21 PDT 2009

There are plenty of low hanging fruit in the JVM for ridiculous
exception catching requirements (the rash of
UnsupportedEncodingException comes to mind). If project coin can't
handle adding semantics for this, then I say: so be it.

It's not -that- hard to fix. Javac already has a 'reachability'
concept. It would have to be expanded slightly to consider the type of
'unambiguous exit'. If it's an exception, then the ARM block no longer
desugars the if (#suppressSecondary) block; it just assumes
suppressSecondary is neccessarily true.

--Reinier Zwitserloot

On Mar 10, 2009, at 00:17, Mark Mahieu wrote:

Yuck.

I guess one way to deal with this would be to track exceptions 'definitely thrown' by statements, and use different translations depending on whether there are any exceptions 'definitely' thrown by the body. Not exactly a trivial addition to the spec though. Mark

On 9 Mar 2009, at 20:06, Neal Gafter wrote: On Mon, Mar 9, 2009 at 11:16 AM, Joshua Bloch <jjb at google.com> wrote: This URL should always point at the latest version: http://docs.google.com/Doc?id=ddv8ts740vnstdfdh

The static exception analysis implied by the proposal's translation doesn't match its dynamic semantics. In the following program snippet, the proposal requires an error message where shown, while the dynamic semantics never allow the reported exception to occur. static BufferedReader getReader(String name) { // any implementation here } public static void main(String[] args) { { try (BufferedReader localVar = getReader(args[0])) { throw new NullPointerException(args[0]); } // required language error: IOException not caught } }

More information about the coin-dev mailing list