Java Enterprise Best Practices

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 an EJBException, as you’ll see next.

EJBException and its subclasses

This exception is thrown by the developer in the EJB implementation class and it’s caught by the container. Throwing an EJBException usually signifies a major error, in which case the container will always do a rollback of the current transaction. This exception should be treated as a NullPointerException: it’s a runtime exception, and in most cases, it should never be caught by the developer. To help diagnose errors, EJBException can be constructed with a causedBy exception—effectively wrapping another exception. ...