Programmers often suppress checked exceptions. That is, they often catch exceptions with a catch block, with the catch body doing nothing or something trivial, such as printing the stack trace. Often the catch body will have a comment stating that the exception is explicitly being ignored.
Exceptions must be handled appropriately. There are few valid reasons for suppressing exceptions; the most common are cases where the client cannot be expected to recover from the underlying problem. In these cases, it is good practice to allow the exception to propagate outwards rather than to catch and suppress the exception.
Catching and suppressing exceptions is considered bad practice for several reasons. Exceptions disrupt the expected control flow of the application. For example, statements in the try block that follow the statement that caused the exception are skipped.
Each catch block must ensure that the program continues only with valid invariants. Consequently, the catch block must either recover from the exceptional condition, re-throw the exception to allow a higher level of abstraction to attempt recovery, or throw an exception that is appropriate to the context of the catch block. When recovery is possible, any instructions inside the the try block whose execution is required must be moved outside the try block to ensure that they are executed.
Noncompliant Code Example
This noncompliant code example catches IOException but fails to handle the exception.
try {
//...
} catch (IOException ioe) {
// Ignore
}
Noncompliant Code Example
Printing the exception's stack trace can be useful for debugging purposes but results in program execution that is equivalent to suppressing the exception. Printing the stack trace can also result in unintentionally leaking information about the structure and state of the process to an attacker.
try {
//...
} catch (IOException ioe) {
ioe.printStacktrace();
}
Note that even though the application reacts to the exception by printing out a stack trace, it proceeds as though the exception were not thrown. That is, the future behavior of the application is unaffected by the throwing of the exception, other than the fact that statements in the try block after the statement that caused the exception are skipped. The IOException indicates that an I/O operation attempted by the application failed; it is unlikely that assuming that the attempted operation succeeded will permit the application to operate correctly.
Compliant Solution (User-corrected data)
This compliant solution attempts to recover from a FileNotFoundException by forcing the user to specify another file when a particular file cannot be found in the user-specific directory.
boolean volatile validFlag = false;
do {
try {
// If requested file does not exist, throws FileNotFoundException
// If requested file exists, sets a Boolean flag validFlag to true
validFlag = true;
} catch (FileNotFoundException e) {
// Ask the user for a different filename
}
} while (validFlag != true);
// Use the file
The user is allowed to access only files in a user-specific directory. This prevents any other IOException that escapes the loop from leaking potentially sensitive file system information. See guideline ERR06-J. Do not allow exceptions to expose sensitive information for additional information.
Compliant Solution (Skeletal Implementation of Exception Reporter)
Proper reporting of exceptional conditions is context-dependent. For example, GUI applications should report the exception in a graphical way, such as through error dialog boxes or status windows. To preserve modularity, most library classes should be able to objectively determine how an exception should be reported; they cannot rely on System.err, on any particular logger, or on the availability of the windowing environment. As a result, library classes that wish to report exceptions should specify the API they will use to report exceptions:
public interface Reporter {
public void report(Throwable t);
}
public class ExceptionReporter {
// Exception reporter that prints the exception to the console (used as default)
private static final Reporter PrintException = new Reporter() {
public void report(Throwable t) {
System.err.println(t.toString());
}
};
// Stores the default reporter. The default reporter can be changed by the user.
private static Reporter Default = PrintException;
// Helps change the default reporter back to PrintException in the future
public static Reporter getPrintException() {
return PrintException;
}
public static Reporter getExceptionReporter() {
return Default;
}
public static void setExceptionReporter(Reporter reporter) {
try {
ExceptionReporterPermission perm = new ExceptionReporterPermission("exc.reporter"); // Custom permission
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
// Check whether the caller has appropriate permissions
sm.checkPermission(perm);
}
Default = reporter; // Change the default exception reporter
} catch (SecurityException se) {
System.out.println("Not allowed"); // or log
}
}
}
This compliant solution specifies both an interface for reporting exceptions which exports the report() method, and also a default exception reporter class that the library can use. The exception reporter can be overridden by subclasses.
The setExceptionReporter method prevents hostile code from maliciously installing a more verbose reporter that leaks sensitive information or that directs exception reports to an inappropriate location, such as the attacker's computer, by limiting attempts to change the exception reporter to callers that have the custom permission ExceptionReporterPermission with target exc.reporter. Refer to guideline SEC10-J. Define custom security permissions for fine grained security for additional information regarding defining custom permissions. Note that it would be inappropriate to use a default permission such as java.util.logging.LoggingPermission here because the logging permission's purpose is to control execution of specific logging methods (such as Logger.setLevel), rather than to control setting the exception reporter itself.
The library may subsequently use the exception reporter in catch clauses:
try {
// ...
} catch (IOException warning) {
ExceptionReporter.getExceptionReporter().report(warning);
// Recover from the exception...
}
Any client code that possesses the required permissions can override the ExceptionReporter with a handler that logs the error, or provides a dialog box, or both. For instance a GUI client using Swing may require exceptions to be reported using a dialog box:
ExceptionReporters.setExceptionReporter(new ExceptionReporter() {
public void report(Throwable exception) {
JOptionPane.showMessageDialog(frame,
exception.toString,
exception.getClass().getName(),
JOptionPane.ERROR_MESSAGE);
});
}
Compliant Solution (Subclass Exception Reporter and Filter Sensitive Exceptions)
Sometimes exceptions must be hidden from the user for security reasons; see guideline ERR06-J. Do not allow exceptions to expose sensitive information. In such cases, one acceptable approach is to subclass the ExceptionReporter class and add a filter() method in addition to overriding the default report() method.
class MyExceptionReporter extends ExceptionReporter {
private static final Logger logger = Logger.getLogger("com.organization.Log");
public static void report(Throwable t) {
try {
final Throwable filteredException = (t instanceof NonSensitiveException_1) ? t : filter(t);
} finally {
// Do any necessary user reporting (show dialog box or send to console)
if (filteredException instanceof NonSensitiveCommonException)
logger.log(Level.FINEST, "Loggable exception occurred", t);
}
}
public static Exception filter(Throwable t) {
if (t instanceof SensitiveForLoggingException_1) { // Do not log sensitive information (blacklist)
return SensitiveCommonException();
}
// ...
return new NonSensitiveCommonException(); // Return for reporting to the user
}
}
The report() method accepts a Throwable instance and consequently handles all errors, checked exceptions, as well as unchecked exceptions. The filtering mechanism is based on a white listing approach wherein only non-sensitive exceptions are propagated to the user. Exceptions that are forbidden to appear in a log file can be filtered in the same fashion; see guideline [FIO08-J. Do not log sensitive information outside a trust boundary]. This approach provides the benefits of exception chaining by reporting exceptions tailored to the abstraction, while also logging the low level cause for later failure analysis [[Bloch 2008]].
Noncompliant Code Example
If a thread is interrupted while sleeping or waiting, it causes a java.lang.InterruptedException to be thrown. But the run() method of interface Runnable cannot throw a checked exception, and so it must handle InterruptedException. This noncompliant code example catches and suppresses InterruptedException.
class Foo implements Runnable {
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// Ignore
}
}
}
This code prevents callers higher up the call stack from determining that an interrupted exception occurred; consequently, they are unable to act on the exception [[Goetz 2006]]. Likewise, if this code was called in its own thread, it prevents the calling thread from knowing that this thread was interrupted.
Compliant Solution
This compliant solution catches the InterruptedException and restores the interrupted status by calling the interrupt() method on the current thread.
class Foo implements Runnable {
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // Reset interrupted status
}
}
}
Consequently, code that is higher up on the call stack (or code from a calling thread) can see that an interrupt was issued [[Goetz 2006]].
Exceptions
ERR00-EX0: Exceptions that occur during the freeing of a resource may be suppressed in those cases where failure to free the resource cannot affect future program behavior. Examples of freeing resources include closing files, network sockets, shutting down threads, etc. Such resources are generally freed in catch or finally blocks, and are never reused during subsequent execution. Consequently, the exception cannot influence future program behavior through any avenue other than resource exhaustion. When resource exhaustion is adequately handled, it is sufficient to sanitize and log the exception for future improvement; additional error handling is unnecessary in this case.
ERR00-EX1: When recovery from an exceptional condition is impossible at a particular abstraction level, code at that level should avoid handling that exceptional condition. In such cases, an appropriate exception must be thrown so that higher level code can catch the exceptional condition and can attempt recovery. The most common implementation for this case is to omit a catch block and consequently allow the exception to propagate normally, as shown below.
// When recovery is possible at higher levels
private void doSomething() throws FileNotFoundException {
// Requested file does not exist; throws FileNotFoundException
// Higher level code can handle it by displaying a dialog box and asking
// the user for the file name
}
Some APIs may limit the permissible exceptions thrown by particular methods. In such cases, it may be necessary to catch an exception and either wrap it in a permitted exception or translate it to one of the permitted exceptions.
Alternatively, when higher level code is also unable to recover from a particular exception, the checked exception may be wrapped in an unchecked exception and re-thrown.
try {
// Requested file does not exist
// User is unable to supply the file name
} catch (FileNotFoundException e) {
throw new IOException(e);
}
ERR00-EX2: "The only situation in which it is acceptable to swallow an interrupt is when you are extending Thread and therefore control all the code higher up on the call stack" [[Goetz 2006]]. In such cases InterruptedException may be caught and suppressed. A interruption request may also be suppressed by code that implements a thread's interruption policy [[Goetz 2006, pg 143]].
Risk Assessment
Ignoring or suppressing exceptions violates the fail-safe criteria of an application.
Guideline |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
ERR00-J |
low |
probable |
medium |
P4 |
L3 |
Automated Detection
Detection of suppressed exceptions is straightforward. Sound determination of which specific cases represent violations of this guideline, and which represent permitted exceptions to the guideline is infeasible. Heuristic approaches may be effective.
Related Vulnerabilities
Bibliography
[[Bloch 2008]] Item 65: "Don't ignore exceptions", Item 62: "Document all exceptions thrown by each method"
[[Goetz 2006]] 5.4 Blocking and interruptible methods
[[JLS 2005]] Chapter 11, Exceptions
[[MITRE 2009]] CWE ID 390 "Detection of Error Condition Without Action"
06. Exceptional Behavior (ERR) 06. Exceptional Behavior (ERR) ERR02-J. Use exceptions only for exceptional conditions