Head First EJB

Remember, Java exceptions can be checked or unchecked

We know that you remember all of this, but just so we’re all speaking the same language here—Java has both checked and unchecked exceptions. Checked as in compiler-checked. If you call a method that declares a throws clause with a checked exception, you must reassure the compiler that you know all about this potential problem, and you’re ready to take the risk. It’s the handle or declare rule. You either wrap the risky method call in a try/catch, or you declare that you, too, throw the exception.

Remember, declaring an exception means ducking it—letting someone else in the call stack deal with it. Declaring an exception is like saying, “I don’t want to catch this exception, because I think someone else can do a better job of handling it (or someone else should be handling it).

If you handle an exception and exit the catch block, it should make no difference whether the exception occurred or not. If it does matter, then you aren’t handling the exception correctly, and you probably should have ducked it instead.

Runtime exceptions are unchecked (they matter only at runtime, not compile time). You can declare them, catch them, and throw them in code any way that you like, but the compiler won’t care. But if your code causes a runtime exception, the call stack/thread of execution you’re running in dies. If that’s the last non-daemon thread ...