Page History

...

Exceptions must be handled appropriately. There are few valid reasons for suppressing exceptions; the least uncommon most common are cases where the client cannot be expected to recover from the underlying problem. In these cases, it is usually good practice to allow the exception to propagate outwards rather than to catch and suppress the exception.

...

This noncompliant code example catches IOException but fails to handle the exception in any way.

try {
  //...
} catch (IOException ioe) { 
  // Ignore 
}

...

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

...

This compliant solution attempts to recover from a FileNotFoundException by forcing the user to specify another file when a particular file does not exist 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

...

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 suppresss suppresses InterruptedException.

class Foo implements Runnable {
  public void run() {
    try {
      Thread.sleep(1000);    
    } catch (InterruptedException e) {
      // Ignore
    }
  }
}

...

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|AA. Bibliography#Goetz 06]\].

Exceptions

EXC00-EX1: It is reasonable to suppress handling an EX0: An exception that occurs within a catch or finally block may be suppressed, such as when closing a FileInputStream object.

EXC00-EX2EX1: 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.

...

try {
  // Requested file does not exist
  // User is unable to supply the file name
} catch (FileNotFoundException e) { 
  throw new RuntimeException(e);
}

*EXC00-EX3EX2:* "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|AA. Bibliography#Goetz 06]\]. In such cases {{InterruptedException}} may be caught and suppressdsuppressed. A interruption request may also be suppressed by code that implements a thread's interruption policy \[[Goetz 2006, pg 143|AA. Bibliography#Goetz 06]\].

...

Ignoring or suppressing exceptions violates the fail-safe criteria of an application.

...

Detection of suppressed exceptions appears to be is straightforward. Sound determination of which specific cases represent violations of this guideline, and which represent permitted exceptions to the guideline appears to be is infeasible. Heuristic approaches may be effective.

...