Page History

Programmers often fall into the trap of suppressing or ignoring checked exceptions. Unless there is a valid reason for ignoring exceptions, such as 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 stage a recoveryrecover from the underlying problem. Even in these cases, it is important to handle them appropriatelyusually 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 that occur in the try block after that follow the statement that caused the exception , do not execute as requiredare skipped.

To Each catch block must ensure that the program does not resume with invalid invariantscontinues only with valid invariants. Consequently, the catch block should immediately stop control flow from proceeding, instead of ignoring or suppressing the exception. If the program is capable of recovering from the exceptional condition, the statements in the try block that are required to be executed, 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 adorns the catch block with an ignore comment and forgoes appropriate exception handlingcatches IOException but fails to handle the exception in any way.

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

...

Printing the exception's stack trace can be useful for debugging purposes but results in program execution that is equivalent to ignoring the exception, as this noncompliant code example demonstrates.

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 if though the exception was were not thrown, that . That is, the future long term behavior of the application does not change based on is unaffected by the throwing of the exception, other than the fact that impending statements in the try block after the statement that caused the exception are skipped. Given that the resulting The IOException indicates that an I/O operation attempted by the application failed, ; it is unlikely that the application will be able to operate successfully by 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.

...

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

Noncompliant Code Example

It is not possible to propagate a checked exception by throwing it from a Runnable object's The run() method of a Runnable object cannot throw a checked exception. Consequently, this noncompliant code example catches and ignores java.lang.InterruptedException but ignores it.

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

AnyThis code prevents callers higher up in the call stack arefrom unable todetermining determine that an interrupted exception occurred and; consequently, they are unable to act on itthe exception \[[Goetz 2006|AA. Bibliography#Goetz 06]\].

...

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: It is also permissible to ignore handling an exception when it is not possible to recover from the exceptional condition at that abstraction level 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, the an appropriate exception must be thrown so that higher level code can try recovering from catch the exceptional condition by catching and handling itand 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 If the higher level code is also incapable of staging a recoveryunable to recover from a particular exception, the checked exception may be wrapped in an unchecked exception and re-thrown.

...

Automated Detection

TODODetection 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

\[[JLS 2005|AA. Bibliography#JLS 05]\] [Chapter 11, Exceptions|http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html]
\[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 65: "Don't ignore exceptions", Item 62: "Document all exceptions thrown by each method"
\[[Goetz 2006|AA. Bibliography#Goetz 06]\] 5.4 Blocking and interruptible methods
\[[JLS 2005|AA. Bibliography#JLS 05]\] [Chapter 11, Exceptions|http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html]
\[[MITRE 2009|AA. Bibliography#MITRE 09]\]  [CWE ID 390|http://cwe.mitre.org/data/definitions/390.html] "Detection of Error Condition Without Action"

...