Howdy,
I'll see if I can do a slightly better job explaining this than I did in the book; I can certainly see how it could look confusing.
There are two main issues:
1) Exceptions you *declare*, and might THROW to the Container
2) Exceptions you *catch* (and handle)
And these are two separate things.
Let's say one bean (Bean A) does a lookup on another bean (Bean B) and calls the other bean's create() method. That means Bean A's method that makes the call to create() must acknowledge (try/catch) the CreateException that might be thrown by Bean B's home create() method.
Bean A does not have to declare this exception in whatever method is doing that code (calling Bean B's create()), but then it means Bean A must handle it.
So if you DO handle an exception, you do not have to declare it, other than the exceptions that are required by the spec for certain methods (like CreateException and RemoveException, etc.).
Now, for methods that you might THROW -- well, you could, for example, throw a InsufficientFunds exception in a bean's business method, to tell the client what went wrong. That means you MUST declare that exception both in your component interface *and* in the bean's implementation method. And that is the method that you will throw to the Container. It is considered an application exception, and you are to throw it to the Container just as you declared it, and the Container will in turn pass that back to the Client, so the client gets the InsufficientFunds exception rather than a more generic RemoteException.
BUT... in ejbActivate() and other callbacks like that, you are *not* allowed to throw the Container an application exception. But what happens if inside your ejbActivate() method you in turn call another bean's method which DOES throw an application exception? Then here is what you must do:
1) Provide a try/catch
2) If you catch the exception, you can either handle it completely OR throw an *unchecked* exception to the Container.
So what you catch, and what you declare, and what you can throw are really separate issues, so there's no inconsistency in the rules. If you handle an exception with a try/catch, there is no reason that you need to throw it to the Container. The only reason to throw exceptions to the Container are if something goes wrong from which you cannot recover (unchecked/system exceptions), or when you want to give the client a chance to recover (application exceptions).
As with any other
Java program, you are ALWAYS free to provide try/catch blocks and never tell the Container that you caught an exception.
Does that help? Please keep asking if this didn't explain it for you.
cheers,
Kathy