EXC14-J. Catch specific exceptions as opposed to the more general RuntimeException or Exception

It is highly unlikely that a method is built to deal with all possible runtime exceptions. Consequently, no method should ever catch RuntimeException. If a method catches RuntimeException, it may receive exceptions it was not designed to handle, such as NullPointerException. Many catch clauses simply log or ignore the enclosed exceptional condition, and normal execution resumes. Runtime exceptions indicate bugs in the program that should be fixed by the developer. They almost always lead to control flow vulnerabilities. Likewise, a method should never catch Exception or Throwable, because this implies catching RuntimeException (RuntimeException extends Exception which in turn extends Throwable).

Noncompliant Code Example

This noncompliant code example takes a String argument and returns true if it consists of a capital letter succeeded by lowercase letters. To handle corner cases, it merely wraps the code in a try-catch block and reports any exceptions that may arise.

boolean isCapitalized(String s) {
  try {
    if (s.equals("")) {
      return true;
    }
    String first = s.substring( 0, 1);
    String rest = s.substring( 1);
    return (first.equals (first.toUpperCase()) &&
	    rest.equals (rest.toLowerCase()));
  } catch (RuntimeException exception) {
    ExceptionReporter.report(exception);
  }
  return false;
}

This code reports a null pointer exception condition if s is a null pointer. However, it also unintentionally catches other exceptions that are unlikely to be handled properly, such as an ArrayIndexOutOfBoundsException resulting from an out of bounds index.

Compliant Solution

Instead of catching RuntimeException, the program should be as specific as possible in catching exceptions.

boolean isCapitalized(String s) {
  try {
    if (s.equals("")) {
      return true;
    }
    String first = s.substring(0, 1);
    String rest = s.substring(1);
    return (first.equals (first.toUpperCase()) &&
	    rest.equals (rest.toLowerCase()));
  } catch (NullPointerException exception) {
    ExceptionReporter.report (exception);
  }
  return false;
}

This code only catches those exceptions that are intended to be caught. For example, a null pointer exception is caught whereas an index-out-of-bounds exception is not caught.

Noncompliant Code Example

This noncompliant code example handles a divide by zero exception initially. Instead of the specific exception type ArithmeticException, a more generic type Exception is caught. This is dangerous as any future exception declaration updates to the method signature (such as, addition of IOException) may no longer require the developer to provide a corresponding handler. Consequently, the recovery process may not be tailored to the specific exception type that is thrown. Furthermore, unchecked exceptions under RuntimeException are also unintentionally caught whenever the top level Exception class is caught.

public class DivideException {
  public static void main(String[] args) {
    try {
      division(200, 5);
      division(200, 0); // Divide by zero
    } catch (Exception e) { System.out.println("Divide by zero exception : " + e.getMessage()); }
  }

  public static void division(int totalSum, int totalNumber) throws ArithmeticException, IOException  {
    int average  = totalSum/totalNumber;
    // Additional operations that may throw IOException...
    System.out.println("Average: " + average);
  }
}

Noncompliant Code Example

This noncompliant code example improves by catching a specific divide-by-zero exception but fails on the premise that it unscrupulously accepts other undesirable runtime exceptions, by catching Exception.

try {
  division(200,5);
  division(200,0); // Divide by zero        
} catch (ArithmeticException ae) { 
  throw new DivideByZeroException(); 
} catch (Exception e) { // DivideByZeroException extends Exception so is checked
  System.out.println("Exception occurred :" + e.getMessage());
}	

Compliant Solution

To be compliant, catch specific exception types especially when the types differ significantly. Here, ArithmeticException and IOException have been unbundled because they fall under very diverse categories.

import java.io.IOException;

public class DivideException {
  public static void main(String[] args) {
    try {
      division(200,5);
      division(200,0); // Divide by zero        
    } catch (ArithmeticException ae) { 
      throw new DivideByZeroException();  // DivideByZeroException extends Exception so is checked 
    } catch (IOException ie) { 
      System.out.println("I/O Exception occurred :" + ie.getMessage()); 
    }	    
  }

  public static void division(int totalSum, int totalNumber) throws ArithmeticException, IOException  {  
    int average  = totalSum/totalNumber; 
    // Additional operations that may throw IOException...
    System.out.println("Average: "+ average);   	
  }
}

DivideByZeroException is a custom exception type that extends Exception.

Exceptions

EX1: A secure application must also abide by [EXC06-J. Do not allow exceptions to transmit sensitive information]. To follow this rule, an application might find it necessary to catch all exceptions at some top-level to sanitize (or suppress) them. This is also summarized in the CWE entries, CWE 7 and CWE 388. If exceptions need to be caught, it is better to catch Throwable instead of Exception [[Roubtsov 2003]].

EX2: Task processing threads such as worker threads in a thread pool or the swing event dispatch thread are allowed to catch RuntimeException when they call untrusted code through an abstraction such as Runnable [[Goetz 2006 pg 161]].

Risk Assessment

Catching RuntimeException traps several types of exceptions not intended to be caught. This prevents them from being handled properly.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[MITRE 2009]] CWE ID 396 "Declaration of Catch for Generic Exception", CWE ID 7 "J2EE Misconfiguration: Missing Error Handling", CWE ID 537 "Information Leak Through Java Runtime Error Message", CWE ID 536 "Information Leak Through Servlet Runtime Error Message"
[[Schweisguth 2003]]
[[JLS 2005]] Chapter 11, Exceptions
[[Tutorials 2008]] Exceptions
[[Doshi 2003]]
[[Muller 2002]]

EXC13-J. Throw specific exceptions as opposed to the more general RuntimeException or Exception      17. Exceptional Behavior (EXC)      EXC15-J. Do not catch NullPointerException