Updated ARM Spec

[Tom Ball]

IMHO, the point of syntactic sugar is to eliminate boilerplate code and/or
patterns that are difficult to implement correctly, not to solve new CS
problems, so any new sugar should be able to be fully described with
existing Java syntax.  For syntactic sugar enhancements, I've found it much
easier to get engineers to reach consensus on a clear code example than on a
spec describing it.  Wasn't that how the enhanced for loops were designed in
Java 5?

So what Java 6 code would you write that fully addresses your concerns here?
 For my own projects, I'd just bail rather than invest in handling a
rare occurrence like this (at least it should be rare), but that bad
attitude is probably why I rarely contribute to language design discussions.
:-)

Tom

If agreement can be reached on exactly what code we're

On Thu, Aug 12, 2010 at 8:28 PM, Neal Gafter <neal at gafter.com> wrote:

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