This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Again... im confused about some declarations in HFEJB...
BEAN PROVIDER�S RESPONSABILITIES (page 544)
1.- If you bussines logic catches (or creates) an application exception, throw it to the container as the application exception.
My question.... --- if i can handle an application exception by a try/catch block, why do i still have to throw it to the container?
5.- if your bussines generates an application exception, you must had declared the exception in both your client interface and you bean class
My Question... ---- if i can handle an application exception by a try/catch block, why do i still have to declare it?
And one more confusion:
THERE ARE NO DUMP QUESTIONS (PAGE 545) Question: Q: ... Does this mean that you can�t throw an application exception from sar, ejbActivate()?; Answer: that�s right�... you can trhow only unchecked exceptions from the container callbacks....
an just a few pages later:
You catch checked exception in you ejbActivate method the method is not into a transaction
what do i supossed to belive? (can or can't) i throw a checked exception from de container callbacks? (ejbActivate(), ejbPassivate()...)
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.
Joined: Jul 22, 2004
Thank you very much kathy... i�ve alredy undertood, haven't i?... do you mean that if i do handle a creteException i don�t have to throw it, but if i do handle, let�s say... a insufficientFounds, do i have to throw it to the container? ... even if both are application?... what's the difference?exceptions? sorry i'm still i litle confufused
Cowgirl and Author
Joined: Oct 10, 2002
Howdy -- don't worry about not understanding it; it probably just means I'm not being clear enough. You never have to throw an exception to the Container if you are able to handle the exception in your own catch block.
The issue is what to do when you cannot handle the exception. In that case, you have to decide what to throw to the Container.
* If you catch a checked exception, the exception might be: 1) One of the EJB application exceptions (CreateException, RemoveException ,etc). OR 2) One of your own application exceptions (InsufficientFunds, CartEmptyException, etc.) OR 3) A checked exception that does not fall in one of the other two categories (IOException, etc.)
If your method catches an EJB app exception (#1), and decides that it cannot handle it, it can throw it back to the Container exactly as-is, but only from a method that actually *declares* the exception, of course. So if in your bean's ejbRemove() you turn around and do your own cascading delete and invoke *another* bean's ejbRemove(), and something goes wrong, you can throw the RemoveException to the Container.
But if you did NOT declare the exception, then #1 and #3 are the same--you MUST throw an EJBException back to the Container, because you obviously can't throw a checked exception that you did not declare on your method, and EJBException is an unchecked exception, so you can always throw it from anywhere. In other words, you can't throw an IOException to the Container! It wasn't expecting that... but you CAN throw an unchecked EJBException to the Container to say, "Something went wrong from which I can't recover, so please roll back the transaction and tell the client something went wrong..."
With #2, your OWN application exceptions, these are declared both in your interface and in your bean, so you are able to throw them to the Container. Remember, you will normally throw these to tell the "client" that something went wrong, so you WANT the client to see the real exception.
Joined: Jul 22, 2004
Thanks Kathy...really�... thank you very much, this time i've understood everything about this...
I also have to thank you that i got my first certification a month ago (SCJP 1.4 +90%). ok, ok, i was the one who estudied, but you made it very easy for me. :roll:
Just for clarify me, about container callbacks exceptions..... WE CAN'T THROW ANY APPLICATION EXCEPTION FROM CONTAINER CALLBACKS DEFINED AT THE BEAN INTERFACE, RIGHT ? BECAUSE CONTAINER CALLBACKS ITS ONLY TO CONTAINER ... (i.e at ejbActivate method I never throw InsuficientBalance)
Will there be such a need to throw customised exceptions from these methods like ejbActivate? They are there for a specific function. And are not meant to contain business processing to be able throw any business exceptions.
Paulo Asterio Nunes
Joined: Jul 06, 2004
I know that is no make sense to any application, but I want know if it may be a pitfall and if it's a java possible.