Exception Revisited

1. Exception and Control Flow

EJ 57: Use exceptions only for exceptional conditions. exceptions are, as their name implies, to be used only for exceptional conditions; they should never be used for ordinary control flow.

So, my next relevant question is: how to define exceptional condition?

And, Solution?

State-testing method or return a distinguished value.

2. Concerns of API Design

2.1 EJ 57: A well-designed API must not force its clients to use exceptions for ordinary control flow.

2.2 EJ 59: Avoid unnecessary use of checked exceptions. 

Overuse of checked exceptions can make an API far less pleasant to use. If a method throws one or more checked exceptions, the code that invokes the method must handle the exceptions in one or more catch blocks, or it must declare that it throws the exceptions and let them propagate outward. Either way, it places a nontrivial burden on the programmer.
The burden is justified if the exceptional condition cannot be prevented by proper use of the API and the programmer using the API can take some useful action once confronted with the exception. Unless both of these conditions hold, an unchecked exception is more appropriate.

2.3 EJ 60: Favor the use of standard exceptions

2.4 EJ 61: Exception Translation

Higher layers should catch lower-level exceptions and, in their place, throw exceptions that can be explained in terms of the higher-level abstraction. While exception translation is superior to mindless propagation of exceptions from lower layers, it should not be overused.

Reference:

1. Effective Java, 2nd Edition