Three kinds of throwables

Principle

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).

Note

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).

Summary

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