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

Exception in enterprise bean

 
Fisher Daniel
Ranch Hand
Posts: 582
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear all,
I am confuse about exception in enterprise bean.
According to ejb 2.0 specification...
An application exception class must not be defined as a subclass of the java.lang.RuntimeException or of the java.rmi.RemoteException.
In my projects, I always make my application exceptions extends RuntimeException. Because of that, I am sure that all my transactions will be rollbacked by Container.
Do it harm my overall application processes?
What are the main differences between extends RuntimeException and extends Exception?
Correct me if I am wrong....
Thanks
daniel
 
Kathy Sierra
Cowgirl and Author
Rancher
Posts: 1589
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy,
The exception model for EJB is that Application exceptions (which must NOT be runtime exceptions, or remote exceptions) are those that the client is expecting, and can possibly recover from. They MUST be declared in your client interfaces, and of course the compiler will keep everyone honest about that because they will be checked exceptions. The idea is that transaction rollback should NOT always be automatic, and that you should have the ability to separate exceptions from bean destruction.
So, if you are running code and find that things have gone horribly wrong, and the bean is possibly corrupt, and of course the transaction must rollback, then throw an EJBException (system exception).
BUT... if things go wrong in a way that didn't necessarily ruin the transaction or the bean itself, so you don't want to kill the bean, then throw an application exception (one of the standard EJB application exceptions: CreateException, RemoveException, ObjectNotFoundException, FinderException, DuplicateKeyException) or else one that you have created by extending something that is NOT RuntimeException or RemoteException.
BUT... many times (perhaps MOST times) even with an application exception you WILL find that you need to rollback the exception (it sounds like that is the problem you are trying to solve). And in that case, the EJB model wants you to go ahead and throw the application exception, but BEFORE you do, call setRollbackOnly() on your context. This will guarantee that the transaction will not commit, while still giving the client a chance to recover without destroying the bean.
Remember, ANY RuntimeException (meaning: non-application exception) will ALWAYS destroy the bean. And bean destruction is not guaranteed to be transparent to the client, EVEN with entity beans.
Does this help? Hey, I just realized that I know a book that has a whole chapter on this...
cheers,
Kathy
 
Fisher Daniel
Ranch Hand
Posts: 582
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Kathy for your excellent explanation.
Now, I know what I should do with me enterprise bean....
I have question again about this....
What the differences between i use a code to rollback transaction and using trans-attribute in ejb-jar.xml ?
Hmm... what is the title a book that has a whole chapter on this?
Is it your book, Head First EJB?
thanks
daniel
[ October 28, 2003: Message edited by: Fisher Daniel ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic