Pitfall - Ignoring or squashing exceptions

suggest change

This example is about deliberately ignoring or “squashing” exceptions. Or to be more precise, it is about how to catch and handle an exception in a way that ignores it. However, before we describe how to do this, we should first point out that squashing exceptions is generally not the correct way to deal with them.

Exceptions are usually thrown (by something) to notify other parts of the program that some significant (i.e. “exceptional”) event has occurred. Generally (though not always) an exception means that something has gone wrong. If you code your program to squash the exception, there is a fair chance that the problem will reappear in another form. To make things worse, when you squash the exception, you are throwing away the information in the exception object and its associated stack trace. That is likely to make it harder to figure out what the original source of the problem was.

In practice, exception squashing frequently happens when you use an IDE’s auto-correction feature to “fix” a compilation error caused by an unhandled exception. For example, you might see code like this:

try {
    inputStream = new FileInputStream("someFile");
} catch (IOException e) {
    /* add exception handling code here */

Clearly, the programmer has accepted the IDE’s suggestion to make the compilation error go away, but the suggestion was inappropriate. (If the file open has failed, the program should most likely do something about it. With the above “correction”, the program is liable to fail later; e.g. with a NullPointerException because inputStream is now null.)

Having said that, here is an example of deliberately squashing an exception. (For the purposes of argument, assume that we have determined that an interrupt while showing the selfie is harmless.) The comment tells the reader that we squashed the exception deliberately, and why we did that.

try {
} catch (InterruptedException e) {
    // It doesn't matter if showing the selfie is interrupted.

Another conventional way to highlight that we are deliberately squashing an exception without saying why is to indicate this with the exception variable’s name, like this:

try { 
} catch (InterruptedException ignored) {  }

Some IDEs (like IntelliJ IDEA) won’t display a warning about the empty catch block if the variable name is set to ignored.

Feedback about page:

Optional: your email if you want me to get back to you:

Table Of Contents