EXC00-J. Do not suppress or ignore checked exceptions

Programmers often suppress or catch-and-ignore checked exceptions. Exceptions must be handled appropriately. There are few valid reasons for ignoring exceptions; the least uncommon are cases where the client cannot be expected to recover from the underlying problem. Even in these cases, it is usually good practice to allow the exception to propagate outwards rather than to catch and ignore the exception.

Catching and suppressing exceptions is considered bad practice for several reasons. Exceptions disrupt the expected control flow of the application. For example, statements in the try block that follow the statement that caused the exception are skipped.

Each catch block must ensure that the program continues only with valid invariants. Consequently, the catch block must either recover from the exceptional condition, re-throw the exception to allow a higher level of abstraction to attempt recovery, or throw an exception that is appropriate to the context of the catch block. When recovery is possible, any instructions inside the the try block whose execution is required must be moved outside the try block to ensure that they are executed.

Noncompliant Code Example

This noncompliant code example catches IOException but fails to handle the exception in any way.

try {
  //...
} catch(IOException ioe) { 
  // Ignore 
}

Noncompliant Code Example

Printing the exception's stack trace can be useful for debugging purposes but results in program execution that is equivalent to ignoring the exception.

try {
  //...
} catch(IOException ioe) { 
  ioe.printStacktrace();
}

Note that even though the application reacts to the exception by printing out a stack trace, it proceeds as though the exception were not thrown. That is, the future behavior of the application is unaffected by the throwing of the exception, other than the fact that statements in the try block after the statement that caused the exception are skipped. The IOException indicates that an I/O operation attempted by the application failed; it is unlikely that assuming that the attempted operation succeeded will permit the application to operate correctly.

Compliant Solution

This compliant solution attempts to recover from a FileNotFoundException by forcing the user to specify another file when a particular file does not exist in the user-specific directory.

boolean volatile validFlag = false;
do {
  try {
    // If requested file does not exist, throws FileNotFoundException
    // If requested file exists, sets a Boolean flag validFlag to true
    validFlag = true; 
  } catch(FileNotFoundException e) { 
    // Ask the user for a different filename 
  }
} while(validFlag != true);
// Use the file

The user is allowed to access only files in a user-specific directory; consequently this approach avoids leaking file system information. See guideline EXC06-J. Do not allow exceptions to expose sensitive information for additional information.

Noncompliant Code Example

The run() method of a Runnable object cannot throw a checked exception. Consequently, this noncompliant code example catches and ignores java.lang.InterruptedException.

class Foo implements Runnable {
  public void run() {
    try {
      Thread.sleep(1000);    
    } catch(InterruptedException e) {
      // Ignore
    }
  }
}

This code prevents callers higher up the call stack from determining that an interrupted exception occurred; consequently, they are unable to act on the exception [[Goetz 2006]].

Compliant Solution

This compliant solution catches the InterruptedException and restores the interrupted status by calling the interrupt() method on the current thread.

class Foo implements Runnable {
  public void run() {
    try {
      Thread.sleep(1000);    
    } catch(InterruptedException e) {
      Thread.currentThread().interrupt(); // Reset interrupted status
    }
  }
}

Consequently, code that is higher up on the call stack can see that an interrupt was issued [[Goetz 2006]].

Exceptions

EXC00-EX1: It is reasonable to ignore handling an exception that occurs within a catch or finally block, such as when closing a FileInputStream object.

EXC00-EX2: When recovery from an exceptional condition is impossible at a particular abstraction level, code at that level should avoid handling that exceptional condition. In such cases, an appropriate exception must be thrown so that higher level code can catch the exceptional condition and can attempt recovery. The most common implementation for this case is to omit a catch block and consequently allow the exception to propagate normally, as shown below.

// When recovery is possible at higher levels
private void doSomething() throws FileNotFoundException {
  // Requested file does not exist; throws FileNotFoundException
  // Higher level code can handle it by displaying a dialog box and asking 
  // the user for the file name
}

Some APIs may limit the permissible exceptions thrown by particular methods. In such cases, it may be necessary to catch an exception and either wrap it in a permitted exception or translate to one of the permitted exceptions.

Alternatively, when higher level code is also unable to recover from a particular exception, the checked exception may be wrapped in an unchecked exception and re-thrown.

try {
  // Requested file does not exist
  // User is unable to supply the file name
} catch(FileNotFoundException e) { 
  throw new RuntimeException(e);
}

EXC00-EX3: "The only situation in which it is acceptable to swallow an interrupt is when you are extending Thread and therefore control all the code higher up on the call stack" [[Goetz 2006]]. In such cases InterruptedException may be caught and ignored. A interruption request may also be swallowed by code that implements a thread's interruption policy [[Goetz 2006, pg 143]].

Risk Assessment

Ignoring or suppressing exceptions violates the fail-safe criteria of an application.

Automated Detection

Detection of suppressed exceptions appears to be straightforward. Sound determination of which specific cases represent violations of this guideline, and which represent permitted exceptions to the guideline appears to be infeasible. Heuristic approaches may be effective.

Related Vulnerabilities

AMQ-1272

Bibliography

[[Bloch 2008]] Item 65: "Don't ignore exceptions", Item 62: "Document all exceptions thrown by each method"
[[Goetz 2006]] 5.4 Blocking and interruptible methods
[[JLS 2005]] Chapter 11, Exceptions
[[MITRE 2009]] CWE ID 390 "Detection of Error Condition Without Action"

06. Exceptional Behavior (EXC)      06. Exceptional Behavior (EXC)      EXC01-J. Use a class dedicated to reporting exceptions