Good old EJBException question...

Question

I've trawled through this forum for a good explanation of EJBException versus RemoteException. I've not found anything I consider particularly intuitive. In fact, I've been amazed by some of the confusion that seems to exist about this, with some people responding with answers that are simply wrong.
So, for my own enlightenment and hopefully the other people who've asked this question - could someone please give an explanation of when to throw an EJBException, when to throw a RemoteException (if ever) and when to throw another type of Exception?
I'm also interested in what the client is guaranteed to receive in each of these cases and what effect this has on the bean that has thrown it.
And just to keep things good and simple could they try to do it without mentioning "the specification"? I have read the specification but would like to know how it manifests itself in the real world and what is considered "good practice" in this matter.
Many thanks in advance.

Answer 1

hey kevin, you causing problems again!
you've probably seen this article by now on EJBExcepitons at the serverside.com but here is the link anyway:
http://www-106.ibm.com/developerworks/java/library/j-ejbexcept.html
EJB exceptions are mine field but there are a couple solid guidelines that i follow when designing my beans with exceptions:
1. Application Exceptions ( not descendants of RuntimeException or RemoteException ) are passed back to the client as is to give them the chance to take the appropriate recovery action. So before you leave your business method, you'd better make damned sure that you don't compromise data integrity. If you can't guarantee data integrity do the EJBContext.setRollbackOnly() thing. Which means that as a client you should get into the habit of doing UserTransaction.getStatus().
2. Runtime Exceptions ( ignore EJBException for now ). I don't catch them but i'm not expecting them, and i don't know what to do with them. Thankfully, the container does (which is to log the exception, throw back RemoteExceptions to remote clients and EJBException to local clients, rollback the transaction and then take the bean instance out of service). So i delegate the handling of runtime exceptions to the container. i do not catch Throwable in my bean methods.
3. System Exception ( EJBExceptions ). Where possible using EJB standard exceptions such as CreateException and FinderException. If my bean throws a checked exception, i need to gauge whether or not i can recover from it. I can't, i wrap it in an EJBException and throw it out for the container to do its stuff ( log, raise client exception, rollback and die ). Otherwise, i perform clean up in my bean to return my resources to the state they were before i started executing this method and raise the checked exception.
In the article above the author's penultimate section talks about when to use an application exception over a system exception. Its always the client the determines which way your go. For example, what should you do during a create ejb you need to look up some data in the database and an SQLException is raised. Within the create method it is an application exception for sure because the system is not compromised, however, from the clients point of view, the bean cannot be created because key data was missing. Hence, the method should wrap the SQLException in an EJBException and throw it out to make sure the bean is not created. (If fact, the method retry something else and if nothing else works raise the EJBException).
cleve