EJB.12.2 Bean Provider's ResponsibilitiesThis section describes the view and responsibilities of the bean provider with respect to exception handling. EJB.12.2.1 Application ExceptionsThe bean provider defines the application exceptions in the throws clauses of the methods of the remote and home interfaces. Because application exceptions are intended to be handled by the client, and not by the system administrator, they should be used only for reporting business logic exceptions, not for reporting system level problems. The bean provider is responsible for throwing the appropriate application exception from the business method to report a business logic exception to the client. Because the application exception does not automatically result in marking the transaction for rollback, the bean provider must do one of the following to ensure data integrity before throwing an application exception from an enterprise bean instance:
An application exception must not be defined as a subclass of the java.lang.RuntimeException , or of the java.rmi.RemoteException . These are reserved for system exceptions (see next subsection). The bean provider is also responsible for using the standard EJB application exceptions ( javax.ejb.CreateException , javax.ejb.RemoveException , javax.ejb.FinderException , and subclasses thereof) as described in Section EJB.9.1.9. Bean providers may define subclasses of the standard EJB application exceptions and throw instances of the subclasses in the entity bean methods. A subclass will typically provide more information to the client that catches the exception. EJB.12.2.2 System ExceptionsThis subsection describes how the bean provider should handle various system-level exceptions and errors that an enterprise bean instance may encounter during the execution of a business method or a container callback method (e.g., ejbLoad ). The enterprise bean business method and container callback methods may encounter various exceptions or errors that prevent the method from successfully completing. Typically, this happens because the exception or error is unexpected, or the exception is expected but the EJB provider does not know how to recover from it. Examples of such exceptions and errors are failure to obtain a database connection, JNDI API exceptions, unexpected RemoteException from invocation of other enterprise beans, [1] unexpected RuntimeException , Java Virtual Machine errors, and so on.
If the enterprise bean method encounters a system-level exception or error that does not allow the method to complete successfully, the method should throw a suitable non-application exception that is compatible with the method's throws clause. While the EJB specification does not prescribe the exact usage of the exception, it encourages the bean provider to follow these guidelines:
Note that the javax.ejb.EJBException is a subclass of the java.lang.RuntimeException , and therefore it does not have to be listed in the throws clauses of the business methods. The container catches a non-application exception, logs it (which can result in alerting the system administrator), and throws the java.rmi.RemoteException (or subclass thereof) to the client. The bean provider can rely on the container to perform the following tasks when catching a non-application exception:
This means that the bean provider does not have to perform any cleanup actions before throwing a non-application exception. It is the container that is responsible for the cleanup. EJB.12.2.2.1 javax.ejb.NoSuchEntityExceptionThe NoSuchEntityException is a subclass of EJBException . It should be thrown by the entity bean class methods to indicate that the underlying entity has been removed from the database. An entity bean class typically throws this exception from the ejbLoad and ejbStore methods, and from the methods that implement the business methods defined in the remote interface. |