ARM: preserve supressed exceptions due to throw in finally block

[Tom Ball]

There is a big difference in the small impact of how secondary exceptions
are stored and printed compared to how generics affected the Java developer
experience.  On the scale of Java changes, ARM's impact should be closer to
enhanced for loops than generics.

Let's also remember the point of having ARM support:  most Java developers
(including myself) can't write truly correct management of nested resource
classes.  Whether this feature can guarantee perfect code or optimally
manages nested exceptions is arguably less important then the fact that it
should emit better code than the developer with a much smaller time
investment on his or her part.  Platform and library writers often forget
that there is a large class of developers who have a schedule gun to their
heads to crank out applications quickly (I can smell gun oil as I write
this), so any small language improvement that reduces development time and
improves reliability is a big win.  My personal regret isn't that more time
isn't being spent on debating this feature, but instead that it's not
already available for my code.

Tom

On Thu, Apr 8, 2010 at 3:45 PM, Neal Gafter <neal at gafter.com> wrote:

> On Thu, Apr 8, 2010 at 12:44 PM, Joe Darcy <Joe.Darcy at sun.com> wrote:
>
> > On 04/08/10 11:27 AM, Neal Gafter wrote:
> >
> >> Carlos-
> >>
> >> This has the same problem as the proposal for handling suppressed
> >> exceptions
> >> in ARM: we have no experience to suggest that this way of preserving
> >> suppressed exceptions is usable in realistic programs.  This
> >> software-engineering aspect of ARM language design seems to have been
> >> largely ignored.  I think more study of such software engineering
> aspects
> >> would be well advised before ARM or any extensions to it are moved into
> >> the
> >> jdk.
> >>
> >> Cheers,
> >> Neal
> >>
> >> On Thu, Apr 8, 2010 at 2:55 AM, Carlos Costa e Silva <carlos at keysoft.pt
> >> >wrote:
> >>
> >>
> >>
> >>
> >
> > I would expect such study to be able to commence in earnest after there
> is
> > a version of ARM available in the JDK for people to play with.
> >
>
> It is unfortunate that such experience is not developed before being moved
> into the jdk.  There have not even been any proposed guidelines for how to
> program in the presence of this mechanism.  Such guidelines would not
> depend
> on having a prototype, and could be analyzed for their compositional
> properties before a prototype is committed to the JDK.  The complete
> absence
> of such guidelines is most troubling and should signal a warning message
> about the language construct itself.
>
> Language features of course evolve and are tuned as people gain experience
> > with them; this was true of generics I would expect this to be true of
> ARM
> > too.
> >
>
> Generics prototypes were available for years before appearing in the JDK.
> At least with generics we had a significant body of experience with their
> use (yes, including wildcards) before the language construct appeared in
> the
> jdk.  But in this case we do not even have the kinds of early programming
> guidelines for the use of the construct in realistic software engineering
> scenarios that we had for generics.
>
> This reminds me a bit of the discussion surrounding erasure (vs
> reification).  Some people who had a naive view of the problem thought we
> were needlessly throwing away information, and "just" wanted us to preserve
> it.  I jokingly offered to have the compiler email the erased type
> parameters to them.  This is a joke because the information in that form is
> useless to them.  Similarly, although we desire not to lose information
> about "discarded" exceptions, there is no evidence that preserving them in
> the way that is proposed will be useful except in very narrow
> circumstances.  "Wait and see" isn't a very satisfying answer; we should
> have more principled reasons to believe in a proposed solution.
>
> Cheers,
> Neal
>
>