You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

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. The thrown exception disrupts the expected control flow of the application and care must be taken to not assume that the expected control flow has happened after catching an exception. The implication of not ignoring an exception is that the application does not assume normal control flow occurred after catching an exception and the application bases its future long term behavior on the fact that the exception was thrown.

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(); }

Note that even though the application reacts to the exception by printing out a stack trace, the application still proceeds as if the exception was not thrown, that is, the future long term behavior of the application does not change based on the throwing of the exception.

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.

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", 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

  • No labels