Exceptions

Rule 2: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors

Java provides three kinds of throwables: CHECKED exceptions, RUNTIME exceptions, and ERRORS.
use checked exceptions for conditions from which the caller can reasonably be expected to recover.
It is not always clear whether you’re dealing with a recoverable conditions or a programming error. For it is up to API designer to indicate whether the error is recoverable or not .
For example,
consider the case of resource exhaustion, which can be caused by a programming error such as allocating an unreasonably large array, or by a genuine shortage of resources. If resource exhaustion is caused by a temporary shortage or by temporarily heightened demand, the condition may well be recoverable.

There are two kinds of UNCHECKED throwables: RUNTIME exceptions and ERRORS.
it is recommended that ERRORS are used by only be JVM to indicate resource deficiencies, invariant failures, or other conditions that make it impossible to continue execution.
it’s best not to implement any new Error subclasses. Therefore, all of the unchecked throwables you implement should subclass RuntimeException
Not only shouldn’t you define Error subclasses, but with the exception of AssertionError, you shouldn’t throw them either.

API designer often forget that Exception itself a object on which arbitrary method can be desined. the sole purpuse of this method is to provide – the code that catches the exception and
and the adiitional information that cased exception to be thrown . some programmers tend to parsing the string representation of exception for ADDITIONAL INFORMATION. it is extremely bad practice .
Because –
Throwable classes seldom specify the details of their string representations, so string representations can differ from implementation to implementation and release to release. Therefore, code that parses the string representation of an exception is likely to be nonportable and fragile.

Example :
Since checked exceptions generally indicate recoverable conditions, it’s especially important for them to provide methods that furnish information to help the caller recover from the exceptional condition.
For example,
suppose a checked exception is thrown when an attempt to make a purchase with a gift card fails due to insufficient funds. The exception should provide an accessor method to query the amount of the shortfall. This will enable the caller to relay the amount to the shopper.
See Item (Rule 7) for more on this topic