Page History

Methods are forbidden to must not throw RuntimeException, Exception, or Exception Throwable. Handling these exceptions requires catching RuntimeException, which is forbidden in guideline ERR14disallowed by ERR08-J. Do not catch RuntimeExceptionNullPointerException or any of its ancestors. Moreover, throwing a RuntimeException can lead to subtle errors, ; for instanceexample, a caller cannot examine the exception to determine why it was thrown , and consequently cannot attempt recovery.

Instead, Methods can throw a more specific exception , subclassed from Exception or RuntimeException. Note that it is permissible to construct an exception class specifically for a single throw statement.

Noncompliant Code Example

This The isCapitalized() method in this noncompliant code example accepts a string and returns true when it the string consists of a capital letter followed by lowercase letters. To handle corner cases, it checks for various exceptional conditions and throws exceptions when they are likely to disrupt normal operationThe method also throws a RuntimeException when passed a null string argument.

boolean isCapitalized(String s) {
  if (s == null) {
    throw new RuntimeException("Null String");
  }
  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()));
}

To properly handle the case of passing in a null string parameter, any code that calls this method must catch RuntimeException, which violates guideline ERR14A calling method must also violate ERR08-J. Do not catch NullPointerException or any of its ancestors to determine whether the RuntimeException was thrown.

Compliant Solution

This compliant solution throws a specific exception (NullPointerException) to denote the particular specific exceptional condition.:

boolean isCapitalized(String s) {
  if (s == null) {
    throw new NullPointerException();
  }
  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()));
}

Note that the null check is redundant; if it were removed, the next subsequent call (to s.equals("")) would throw a NullPointerException if when s were is null. However, the explicit null check is good form, because it explicitly indicates the programmer's intent. More complex code may require explicit testing of invariants and appropriate throw statements.

Noncompliant Code Example

This noncompliant code example uses a broad specifies the Exception class in the throws declaration clause of the method .declaration for the doSomething() method:

private void doSomething() throws Exception {
  //...
}

Compliant Solution

To be compliant, be as specific as possible when declaring exceptions while continuing to respect the required abstraction level.

private void doSomething() throws IOException {
  //...
}

Using instanceof to check for narrower exceptions in a general catch block is often insufficient; it is usually impossible to enumerate all possible exceptions that the code could throw.

Compliant Solution (Wrapping)

Occasionally it is necessary to invoke library code that can throw any exception. While it is advisable to redesign the library code to be specific about which exceptions it throws, this is not always possible.

This compliant solution catches any exception thrown, and wraps it inside a custom exception, thereby limiting the exceptions that can be thrown. This compliant solution declares a more specific exception class in the throws clause of the method declaration for the doSomething() method:

class DoSomethingException extends Exception {
  public DoSomethingException(Throwable cause) {
    super( cause);
  }
    
  // other methods
};

private void doSomething() throws DoSomethingExceptionIOException {
  try {
    // code that might throw an Exception
  } catch (Throwable t) {
    throw new DoSomethingException(t);
  }
}

This code is valid by EX0 of guideline ERR14-J. Do not catch RuntimeException.

Exception wrapping is a common technique to safely handle unknown exceptions, for another example, see guideline ERR10-J. Do not let code throw undeclared checked exceptions.

Exceptions

...
}

Exceptions

ERR07-JEXC13-EX0: Classes that sanitize exceptions to comply with a security policy are permitted to translate specific exceptions into more general exceptions. This translation could potentially result in throwing RuntimeException, Exception, or Exception Throwable in some cases, depending on the details requirements of the security policy.

Risk Assessment

Throwing RuntimeException and , Exception, or Throwable prevents classes from catching the intended exceptions without catching other unintended exceptions as well.

Related Vulnerabilities

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

Bibliography

\[[Goetz 2004b|AA. Bibliography#Goetz 04b]\]
\[[MITRE 2009|AA. Bibliography#MITRE 09]\] [CWE ID 397|http://cwe.mitre.org/data/definitions/397.html] "Declaration of Throws for Generic Exception", [CWE ID 537|http://cwe.mitre.org/data/definitions/537.html] "Information Leak Through Java Runtime Error Message"
\[[Tutorials 2008|AA. Bibliography#Tutorials 08]\] [Unchecked Exceptions --- The Controversy|http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html]

Automated Detection

Related Guidelines

Bibliography

...

Image Added Image Added Image AddedIDS05-J. Do not log unsanitized user input      06. Exceptional Behavior (ERR)      ERR14-J. Do not catch RuntimeException