ARM: preserve supressed exceptions due to throw in finally block
Neal Gafter
neal at gafter.com
Thu Apr 8 16:26:53 PDT 2010
On Thu, Apr 8, 2010 at 4:12 PM, Tom Ball <tball at google.com> wrote:
> 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.
>
Should be, true. And yet we don't even have any proposed guidelines for
programming in the presence of the proposed handling of suppressed
exceptions.
> 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.
I wasn't expecting optimality. I'd settle for composable and usable. But
we don't even have any reason to believe it will be that.
> 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.
The proposed handling of suppressed exceptions isn't that by any stretch of
the imagination. At least, not based on anything written about it so far.
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.
>
I understand the attraction of
just-get-something-working-now-and-worry-about-it-later. That works very
well for web-based applications where compatibility isn't important. But it
doesn't work so well with programming languages. Your six months of glad
would lead to six+ years of regret.
More information about the coin-dev
mailing list