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.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
EXC00-J |
low |
probable |
medium |
P4 |
L3 |
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"
10. Exceptional Behavior (EXC) 10. Exceptional Behavior (EXC) EXC01-J. Do not allow exceptions to transmit sensitive information