Handle Exceptions in EJB Code Correctly
Handling exceptions in a distributed J2EE environment can be confusing and very messy at times. Because most exceptions are never thrown in a properly debugged application, you might tend to ignore them, or just print them out to see where the error is. Nevertheless, writing a robust application requires you to properly deal with all possible error conditions that might appear.
To see how and where to handle various EJB exceptions, it’s useful to separate them into three basic types:
-
RemoteException This exception is declared in all remote interfaces exposed by an EJB. It is meant to be caught by the client of an EJB, and it usually indicates a network problem. A class implementing an EJB really cannot throw this type of exception. If you need to propagate a network problem (i.e., call another remote object and receive a
RemoteException), you should always wrap it in anEJBException, as you’ll see next.-
EJBExceptionand its subclasses This exception is thrown by the developer in the EJB implementation class and it’s caught by the container. Throwing an
EJBExceptionusually signifies a major error, in which case the container will always do a rollback of the current transaction. This exception should be treated as aNullPointerException: it’s a runtime exception, and in most cases, it should never be caught by the developer. To help diagnose errors,EJBExceptioncan be constructed with acausedByexception—effectively wrapping another exception. ...