Proposal: Automatic Resource Management

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=ddv8ts74_0vnstdfdh
>>
>> 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