EXC00-J. Do not suppress or ignore checked exceptions

Programmers often fall into the trap of suppressing or ignoring checked exceptions. Unless there is a valid reason for ignoring exceptions, such as the client cannot be expected to stage a recovery, it is important to handle them appropriately.

Noncompliant Code Example

In this noncompliant example, the programmer leaves the catch block adorned with an ignore comment.

try {
  //...
}catch(IOException ioe) { /* ignore */ }

Noncompliant Code Example

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

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

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.

try {
  // Requested file does not exist
}catch(FileNotFoundException) { /* ask the user for a different filename */ }

Exceptions

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

EX2: It is also permissible to ignore the exception when the client cannot be expected to recover from the exception easily.

Risk Assessment

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

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[JLS 05]] Chapter 11, Exceptions
[[Bloch 08]] Item 65: "Don't ignore exceptions", Item 62: "Document all exceptions thrown by each method"
[[MITRE 09]] CWE ID 390 "Detection of Error Condition Without Action"

11. Exceptional Behavior (EXC)      11. Exceptional Behavior (EXC)      EXC01-J. Do not allow exceptions to transmit sensitive information