.

.

An APPLICATION exception class MUST be a subclass (direct or indirect) of java.lang.Exception. An application exception class MUST NOT be defined as a subclass of the java.lang.RuntimeException, or of the java.rmi.RemoteException. These are reserved for SYSTEM exceptions.

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).

The enterprise bean business method, onMessage method, or container callback method 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 exceptions, unexpected RemoteException from invocation of other enterprise beans, unexpected RuntimeException, JVM errors, and so on.

Bean Providers MAY define subclasses of the standard EJB application exceptions and throw instances of the subclasses in the enterprise bean methods. A subclass will typically provide more information to the client that catches the exception.

If the enterprise bean method encounters a SYSTEM-level exception or error that does not allow the method to successfully complete (failure to obtain a database connection, JNDI exceptions, unexpected RemoteException from invocation of other enterprise beans, unexpected RuntimeException, JVM errors), 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:

• If the bean method encounters a RuntimeException or error, it should simply propagate the error from the bean method to the Container (i.e., the bean method does not have to catch the exception).
• If the bean method performs an operation that results in a checked exception that the bean method CANNOT recover, the bean method should throw the javax.ejb.EJBException that wraps the original exception.
• Any other unexpected error conditions should be reported using the javax.ejb.EJBException.

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 [SYSTEM] exception; logs it (which can result in ALERTING the SYSTEM Administrator); and, unless the bean is a message-driven bean, throws the java.rmi.RemoteException (or subclass thereof) to the client if the client is a REMOTE client, or throws the javax.ejb.EJBException (or subclass thereof) to the client if the client is a LOCAL client. The Bean Provider can rely on the Container to perform the following tasks when catching a non-application exception:

• The transaction in which the bean method participated will be rolled back.
• No other method will be invoked on an instance that threw a non-application exception.

This means that the Bean Provider does not have to perform any cleanup actions before throwing a non-application [SYSTEM] exception. It is the Container that is responsible for the cleanup.

The 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 COMPONENT interface.

________________
Author: Mikalai Zaikin. Please Click Here to visit Authors site for any updates and changes to the study notes.

First Page: SCBCD Study Notes : Chapter 12 : Exceptions (Part 1)