Effective Java Summary

Item 58: Check v/s unchecked exception

Three kinds of throwables

Throwables Checked Recoverable
checked exceptions Y Y
runtime exceptions N N
errors N N


  1. Use checked exceptions for conditions from which the caller can reasonably be expected to recover.
  2. Code that parses the string representation of an exception is likely to be non portable and fragile. Since the toString() implementation may change from release to release (Item 10).
  3. Provide methods that furnish information that could help the caller to recover.

    For example, suppose a checked exception is thrown when an attempt to make a purchase with a gift card fails because the card doesn’t have enough money left on it. The exception should provide an accessor method to query the amount of the shortfall, so the amount can be relayed to the shopper

  4. Use runtime exceptions to indicate programming errors. -The great majority of runtime exceptions indicate precondition violations. (e.g. ArrayIndexOutOfBoundException).


All of the unchecked throwables you implement should subclass RuntimeException directly or indirectly.

Never use behaviorally identical to ordinary checked exceptions (which are subclasses of Exception but not RuntimeException).

Sub Class of Exceptions:

The unchecked exceptions classes are the class RuntimeException and its subclasses, and the class Error and its subclasses. All other exception classes are checked exception classes. The Java API defines a number of exception classes, both checked and unchecked. Additional exception classes, both checked and unchecked, may be declared by programmers. See §11.5 for a description of the exception class hierarchy and some of the exception classes defined by the Java API and Java virtual machine.

The following picture illustrates the Exception hierarchy:

alt text

The class Error and its subclasses are exceptions from which ordinary programs are not ordinarily expected to recover and, as explained in 11.5 The Exception Hierarchy:

The class Error is a separate subclass of Throwable, distinct from Exception in the class hierarchy, to allow programs to use the idiom:

} catch (Exception e) {

to catch all exceptions from which recovery may be possible without catching errors from which recovery is typically not possible.

To summarize, RuntimeException are a subset of unchecked exceptions for exceptions from which recovery is possible (but unchecked exception is not a synonym of RuntimeException as many are answering here).


Transactions are roll-back automatically for Unchecked exception but needed to be done manually for checked exception (or change in declaration for automatic roll-back).


Use checked exceptions for recoverable conditions and runtime exceptions for programming errors. Of course, the situation is not always black and white.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s