Feedback and comments on ARM proposal - resend

[Bob Lee]

On Mon, Mar 9, 2009 at 6:44 PM, Neal Gafter <neal at gafter.com> wrote:

> To address this problem, that is neither a necessary or particularly
> useful technique.  It is not useful because using this technique to
> properly report or log these suppressed exceptions would be very
> difficult using this API.  One would effectively have to add code to
> most catch clauses in a code base - even the ones generated by this
> desugaring - because any one of them may have suppressed exceptions
> attached.


I can't disagree more, mostly because I don't know why you'd have to "add
code to most of the catch clauses in a code base." It sounds like you're
complaining about how hard it's going to be to handle this useful new
information that we don't have access to at all today.

As someone who has spent a long time thinking about exception handling in
Java apps (from the 1.3 days:
http://weblogs.java.net/blog/crazybob/archive/2004/02/exception_handl.html),
I think the suppressed exception API is a brilliant general solution.
Without this feature, you'd normally just log the suppressed exception. In
other words, at run time you have two exceptions that you know go together,
but you're forced to send them down separate paths (throw one, log one),
only to have the programmer later try to re-correlate them using a server
ID, timestamp and thread ID. In contrast, the suppressed exception list
keeps everything tied together in a nice little package. The suppressed
exceptions are logged automatically if you just print the stack trace. Or
you can can handle them accordingly in your customized exception handler,
but doing so will usually require a code change in only one place within
your system, not every catch block.

In other words, I think the suppressed exception API is both "necessary" and
"particularly useful" independent of this proposal.

Also, we already have a system API: java.util.logging.Handler :-)

Bob