A bug with automatic variables and finally

[Michael Thomas]

Tim Wilkinson writes:
 > But what I want to know is, what do Javasoft claim for runtime
 > exceptions?
 > Do they really expect this kind of behaviour, and if they do can someone
 > point me at the text so I can read it then go and have a bit of a cry.

   Given the original example, I can't imagine any
other interpretation of the finally clause holding
valid data as being the correct one; it would sort
of make finally {} be somewhat useless at its
stated purpose: a guaranteed cleanup hook.
   I'm sort of at a loss though: is this to say
that: 

    int i = 3;
    try {
	// generate some run time error 
    } catch (SomeError) {
        System.out.println ("i ="+i)
    }
    
is broken too? If it isn't why would the finally
clause be so much harder to insure validity? It
seems to me that you'd just cdr through the
exceptions on the stack and execute the finally
clause (after the catches, I suppose) with 
the same calling frame's environment.
   If it is broken, what is the overall problem of
causing registers to be written back to their
shadow locations at the point the exception
happens, rather than trying to be proactive about
it?

		Mike