Page History

...

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.

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 suppressing the exception. Printing the stack trace can also result in unintentionally leaking information about the structure and state of the process to an attacker.

...

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 cannot be found in the user-specific directory.

...

The user is allowed to access only files in a user-specific directory. This prevents any other IOException that escapes the loop from leaking potentially sensitive file system information. See guideline EXC06-J. Do not allow exceptions to expose sensitive information for additional information.

Noncompliant Code Example

If a thread is interrupted while sleeping or waiting, it causes a java.lang.InterruptedException to be thrown. But the run() method of interface Runnable cannot throw a checked exception, and so it must handle InterruptedException. This noncompliant code example catches and suppresses InterruptedException.

...

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|AA. Bibliography#Goetz 06]\].  Likewise, if this code was called in its own thread, it prevents the calling thread from knowing that this thread was interrupted.

Compliant Solution

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

...

Consequently, code that is higher up on the call stack (or code from a calling thread) can see that an interrupt was issued \[[Goetz 2006|AA. Bibliography#Goetz 06]\].

Exceptions

EXC00-EX0: An exception that occurs within a catch or finally block may be suppressed, such as when closing a FileInputStream object.

...

*EXC00-EX2:* "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|AA. Bibliography#Goetz 06]\]. In such cases {{InterruptedException}} may be caught and suppressed. A interruption request may also be suppressed by code that implements a thread's interruption policy \[[Goetz 2006, pg 143|AA. Bibliography#Goetz 06]\].

Risk Assessment

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

Automated Detection

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

Related Vulnerabilities

AMQ-1272

Bibliography

\[[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"

...