Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Agile forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

is HFEJB contradictory?

 
Jezreel Canav
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

SCENARIOS(page 547)

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()...)

can anybody explain me this?... thanks
 
Kathy Sierra
Cowgirl and Author
Rancher
Posts: 1589
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Jezreel Canav
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Kathy Sierra
Cowgirl and Author
Rancher
Posts: 1589
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

cheers,
Kathy
 
Jezreel Canav
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:
 
Tina Desai
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hey Kathy u talk Java!
Tina
 
Paulo Asterio Nunes
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kathy,

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)


thanx and cheers to all !

Paulo Nunes
Brazil
 
Tina Desai
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Tina
 
Paulo Asterio Nunes
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tina,

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.

kisses ,

Paulo Nunes
Brazil
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic