Help coderanch get a
new server
by contributing to the fundraiser
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Pg 556 Exception scenarios answers.

 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,
I could not find answers to all the scenarios in page 556, here is a compilation of answers(mine and borrowed from forum). Please post your comments if anything is wrong:

1. A message-drive bean's onMessage() method catches an application exception. Can it rethrow the application exception to the container?
-- No, the onMessage() method does not declare any application exceptions and hence cannot throw the application exception. It can wrap the exception in a runtime exception and rethrow it.

2. A session bean using CMT has a method marked with the NotSupported transaction atrribute While the method is running. the bean calls setRollbackOnly() on its context. will this cause an exception? What kind?
-- Yes, it will cause an exception. It will be an illegalStateException.

3. A message-drive bean, in the onMessage() method, calls getCallerPrincipal(). What happens?
-- Again, an illegalStateException is thrown

4. A session bean using CMT has a method marked with the Madatory transaction attribute. The client calling the method is not in a transaction. What happens?
-- TransactionRequiredException/TransactionRequiredLocalException is thrown.

5. A bean realizes it can't commit a transaction, but it doesn't want the client to get an exception. What can the bean do?
-- Call the setRollBackOnly method and simple suppress the application exception.

6. A bean wants the client to get an application exception, but the bean still wants the transaction to commit. What should the bean do?

-- Simply throw the Application exception as is. It does not have to do anything more.
Regards.
 
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Perfect
 
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for having started this thread! And now about one and a half year later do I try to activate it again from its passivated state because I like it and have a few comments ...

1) Yes, but if the exception is wrapped should it be wrapped as an EJBExcpetion which of course is a RuntimeExcpetion. Alternatively, if the circumstances is appropriate or permits it, could it not just consume the exception?

4) Because they said client would I have answered TransactionRequiredException if I must choose one (on the exam for example) because client if not more exactly specified is a someone that is calling the method remotely.

Maybe someone else have more comments of valuea to add?
[ June 23, 2007: Message edited by: Jonny Andersson ]
 
Yes, of course, and I accept that blame. In fact, i covet that blame. As does this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/t/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic