Page History

Wiki MarkupMethods should rarely throw {{RuntimeException}} or {{Exception}}, because handling these exceptions requires catching {{RuntimeException}}, which is forbidden in guideline [Methods are forbidden to throw RuntimeException or Exception; handling these exceptions requires catching RuntimeException, which is forbidden in guideline EXC14-J. Catch specific exceptions as opposed to the more general RuntimeException or Exception]. Moreover, throwing a {{RuntimeException}} can lead to subtle errors, for instance, a caller who fails to retrieve a return value from an offending method is unable to check for appropriate feedback. The Java Language Specification (Section 8.4.7 Method Body) allows the declaration of a method with a return type without making it necessary to return a value if a runtime exception is thrown from within the method \[[JLS 2005|AA. Bibliography#JLS 05]\]caller cannot examine the exception to determine why it was thrown, and consequently cannot attempt recovery.

Instead, prefer throwing a more specific exception, subclassed from Exception. It Note that it is permissible to construct an exception class specifically for a single throw statement.

...

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

Although the explicit throw statement is redundant in this small example, more complex code may require explicit testing of invariants and appropriate throw statements.

Noncompliant Code Example

...

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

...

Using instanceof to check for narrower exceptions in a general catch block is not always helpful because often insufficient; it is usually impossible to enumerate all the possible exceptions that the code is capable of throwingcould throw.

Exceptions

EXC13-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 or Exception in some cases, depending on the details of the security policy.

EXC13-EX1: Widely used pre-existing APIs whose previous versions contain methods that throw RuntimeException or Exception may continue to do so, to preserve backwards compatibility. We strongly encourage maintainers of such APIs to consider deprecating such methods, replacing them with methods that throw more specific exceptions.

Risk Assessment

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

Automated Detection

TODO

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"
\[[Goetz 2004b|AA. Bibliography#Goetz 04b]\]
\[[Tutorials 2008|AA. Bibliography#Tutorials 08]\] [Unchecked Exceptions — The Controversy|http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html]

...