Updated ARM Spec

[Neal Gafter]

When a stack overflow exception suppresses another exception, I assume
it's suppressed exception list will be set.  But since there is only
one such exception allocated by the VM, this will overwrite any data
previously stored there.  Will the VM be modified to comply with this
specification by allocating a new stack-overflow exception each time?
Same question for out-of-memory error.

On Thursday, August 5, 2010, Joe Darcy <joe.darcy at oracle.com> wrote:
> Joe Darcy wrote:
>> Greetings.
>>
>> Starting with Project Coin proposal for Automatic Resource Management
>> (ARM), in consultation with Josh Bloch, Maurizio, Jon, and others, Alex
>> and I have produced a specification for ARM blocks that is much closer
>> to Java Language Specification (JLS) style and rigor. The specification
>> involves changes to the existing JLS section 14.20 "The try statement,"
>> and will eventually introduce a new subsection 14.20.3 "Execution of
>> try-with-resources," although the specification below is not partitioned
>> as such. Non-normative comments about the specification text below
>> appear inside "[]". Differences between the new specification and the
>> earlier Project Coin proposal for ARM are discussed after the specification.
>>
>>
>>
>
> [snip]
>
>> * Adjustments to the suppressed exception logic: in the present
>> specification, an incoming primary exception will suppress an Exception
>> thrown by a close method; however, if the close method throws an error,
>> that error is propagated out without suppressing an incoming primary
>> exception. Possible alternatives include having a primary exception in a
>> try-with-resource statement suppress all subsequent Throwables
>> originating in the statement and having a non-Exception thrown by a
>> close suppress any incoming primary exception.
>>
>> These alternatives could be implemented by replacing the translated code
>>
>>               try {
>>                 #resource.close();
>>               } catch(Exception #suppressedException) {
>>
>> #primaryException.addSuppressedException(#suppressedException);
>>               }
>>
>> with
>>
>>               try {
>>                 #resource.close();
>>               } catch(Throwable #suppressedException) {
>>
>> #primaryException.addSuppressedException(#suppressedException);
>>               }
>>
>> or
>>
>>               try {
>>                 #resource.close();
>>               } catch(Exception #suppressedException) {
>>
>> #primaryException.addSuppressedException(#suppressedException);
>>               } catch(Throwable #throwable) {
>>                 #throwable.addSuppressedException(#primaryException);
>>                 throw #throwable;
>>               }
>>
>> respectively.
>>
>> -Joe
>>
>
> We've decided to change the specification to the first alternative,
> where an incoming primary suppresses all Throwables rather than just
> subclasses of java.lang.Exception.
>
> The initial code push [1] actually implemented those semantics; a test
> has been added to verify the newly specified behavior [2].
>
> -Joe
>
> [1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/13354e1abba7
> [2] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/38e2c23309f1
>
>
>