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 */ }

Although, not explicitly required by this recommendation, failure tolerant systems must also catch and handle unexpected unchecked exceptions resulting from programming errors.

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