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 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(IOException) { /* ask the user for a different filename */ }

Exceptions

It is reasonable to ignore an exception which occurs within a catch or finally block, such as while trying to close a FileInputStream object. It is also permissible 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"
[[MITRE 09]] CWE ID 390 "Detection of Error Condition Without Action"

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