Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Sharpen excercise on page 547(Exception)

 
Gemini Moses
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Asnwers are
1. A
2. D
3. D
4 C, D

Anyone?

Thanks
Gemini
[ March 21, 2005: Message edited by: Gemini Moses ]
 
amol deshpande
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question please...........dont have HF on cyber cafe@@@@
Amol.
 
Gemini Moses
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You catch a checked exception in your ejbActivate method. The method is not in a transaction D

a DivideByZero exception occurs as your business logic is running. you do not have a try/catch for this. D

you throw a CreateException from your ejbCreate() method. and you realize that you probably cannot safely complete your transaction D

you catch a checked exception in a business method, and realize that your bean is probably corrupt. C, D

A. Throw an EJBException
B. Throw a RemoteException
C. Invoke setRollbackOnly()
D. Allow the exception to propogate (in other words duck it)

Here you go..

Gemini
 
Chengwei Lee
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You catch a checked exception in your ejbActivate method. The method is not in a transaction D


We cannot possibly throw any checked application exception from the ejbActivate method, except by throwing the RemoteException. Other than that, no other application exceptions could can thrown at all. But RemoteException is provided for backward compatibility for EJB 1.0. Since we're using EJB 2.0, we shouldn't be throwing RemoteException, hence there's no way we can propagate the checked exception. We should wrap it with EJBException & rethrow it. [A]

a DivideByZero exception occurs as your business logic is running. you do not have a try/catch for this. D


Agreed. This should be a Runtime exception. Hence, the bean should duck it.

you throw a CreateException from your ejbCreate() method. and you realize that you probably cannot safely complete your transaction D


Since we cannot safely complete the transaction, the bean should call setRollbackOnly() and then propagate the CreateException. The bean instance may not be corrupted, hence we do not need to discard it yet. [C, D]


you catch a checked exception in a business method, and realize that your bean is probably corrupt. C, D


An application exception doesn't cause the container to discard the corrupted bean instance. You should wrap the checked exception in EJBException & throw it. This will cause the container to log the exception, mark the transaction for rollback & discard the bean instance. [A]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic