Page History

The merits of exception handling are challenged when programmers do not realize how exceptions should be treated. Imprecise handling can lead to loss of critical information, on the other hand, being too specific can result in verbose (unreadable) code.

Noncompliant Code Example

In this noncompliant code example, a divide by zero exception was handled initially. Instead of the specific exception type ArithmeticException, a more generic type Exception was caught. This is dangerous since any future exception updates to the method signature (such as, addition of IOException here) may no longer require the developer to provide a handler. Consequently, the recovery process may not be tailored to the specific exception type that gets thrown.

Additionally, unchecked exceptions under RuntimeException are also unintentionally caught when the top level Exception class is caught.

import java.io.IOException;

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; 
    System.out.println("Average: "+ average);   	
  }
}

Compliant Solution

To be compliant, catching specific exception types is advisable especially when the types differ significantly. Here, Arithmetic Exception and IOException have been unbundled as they belong to 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) { System.out.println("Divide by zero exception : " + ae.getMessage()); }
      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; 
    System.out.println("Average: "+ average);   	
  }
}

There are several other antipatterns that must be avoided:

• Do not supress/ignore exceptions: This happens when an empty catch block is defined. The program catches the exception but does not perform any recovery or notification
• Masking of original exception by a new one: A new exception within a block may in certain cases mask the original exception
• Logging the same exception more than once: This creates ambiguity while tracing
• Throwing Exception and Throwable
• Encapsulating the original exception and throwing a completely new exception from the block

Risk Assessment

Not handling exceptions properly may result in information being lost, problems being overlooked, or too much information being passed to the user.

Automated Detection

TODO

Related Vulnerabilities

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

References

\[[JLS 05|AA. Java References#JLS 05]\] [Chapter 11, Exceptions|http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html]
\[[Tutorials 08|AA. Java References#tutorials 08]\] [Exceptions|http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html]
\[[Doshi 03|AA. Java References#Doshi 03]\]
\[[Müller 02|AA. Java References#Müller 02]\]

10. Exceptional Behavior (EXC)      10. Exceptional Behavior (EXC)      EXC01-J. Do not allow exceptions to transmit sensitive information