Re: Thumbs up for suppressable exceptions in JDK 1.7

From:

Daniel Pitts <newsgroup.nospam@virtualinfinity.net>

Newsgroups:

comp.lang.java.programmer

Date:

Thu, 29 Sep 2011 11:25:57 -0700

Message-ID:

<XK2hq.1$eF7.0@newsfe20.iad>

On 9/29/11 9:05 AM, Daniele Futtorovic wrote:

On 27/09/2011 21:43, Tom Anderson allegedly wrote:

On Tue, 27 Sep 2011, Roedy Green wrote:

On Tue, 27 Sep 2011 09:31:03 +0200, Jan Burse<janburse@fastmail.fm>
wrote, quoted or indirectly quoted someone who said :

Was just playing around with suppressable exceptions in JDK 1.7. This
looks like a great improvement for bug hunting!
... 5 more

I think you need some exposition on why this is a good thing.

It avoids this common mistake:

try {
     doSomethingWhichMightThrowAnException();
}
finally {
     doSomeCleanupWhichMightThrowAnException();
}

In that code, if both methods throw an exception, you will only see the
second. The first exception - the one which actually caused the problem
- will be lost. It's as if the VM has a very short attention span, and
can only focus on whatever exception was most recently thrown.

In Java 7, you can put the cleanup into the close() method of an
(Auto)Closeable, and use the try-with-resources form:

class Thing implements AutoCloseable {
     public void close() throws AnException {
         doSomeCleanupWhichMightThrowAnException();
     }
}

try (Thing t = new Thing()) {
     doSomethingWhichMightThrowAnException();
}

There, the compiler will arrange things so that if close() does throw an
exception, it will be 'suppressed', and tagged on to the exception
coming from doSomethingWhichMightThrowAnException() as a suppressed
exception.

tom

Indeed, but even more generally, we can from now on register
"suppressed" exceptions ourselves, as Jan's code and the JSE7 Javadoc
for java.lang.Throwable show. Great Thing IMHO. Closes a hole that's
been lurking there for a very long time.

Thanks Jan for bringing this to my attention.

This will definitely be a big help debugging issues. It may also help
fill up log files faster ;-). I can see it being extremely useful in a
try/catch/retry scenario (such as a service which tries a few times to
connect to a remote machine, and gets a different error each time).

I want to read up on it, but I wonder if it will help with this
(unfortunate) situation:

try {
    buggyCodeThrowsNullPointerException();
} catch (Exception oopsThisWasIgnoredByLazyProgrammer) {
    throw new BusinessLayerSpecificException(
         "Unable to process request for no good reason.");
}

This suppresses a bug, but the original programmer wasn't thinking about
potential bugs, only recoverable exceptions. The exception is
effectively suppressed.