Application exceptions include standard EJB application exceptions and custom application exceptions. The standard EJB application exceptions are CreateException, FinderException, ObjectNotFoundException, DuplicateKeyException, and RemoveException. These exceptions are thrown from the appropriate methods to indicate that a business logic error has occurred. Custom exceptions are exceptions developed for specific business problems. We cover developing custom exceptions in Chapter 11.

Runtime exceptions are thrown from the virtual machine itself and indicate that a fairly serious programming error has occurred. Examples include the NullPointerException and IndexOutOfBoundsException. These exceptions are handled by the container automatically and should not be handled inside a bean method.

You will notice that all the callback methods (ejbLoad( ), ejbStore( ), ejbActivate( ), ejbPassivate( ), and ejbRemove( )) throw an EJBException when a serious problem occurs. All EJB callback methods declare the EJBException and RemoteException in their throws clauses. Any exception thrown from one of the callback methods must be an EJBException or a subclass. The RemoteException type is included in the method signature to support backward compatibility with EJB 1.0 beans. Its use has been deprecated since EJB 1.1. RemoteExceptions should never be thrown by callback methods of EJB 2.0 or EJB 2.1 beans.

Checked exceptions thrown by other subsystems should be wrapped in an EJBException or application exception and rethrown from the method. Several examples of this can be found in the previous example, in which a SQLException that was thrown from JDBC was caught and rethrown as an EJBException. Checked exceptions from other subsystems, such as those thrown from JNDI, JavaMail, and JMS, should be handled in the same fashion. The EJBException is a subtype of the RuntimeException, so it doesn’t need to be declared in the method’s throws clause. If the exception thrown by the subsystem is not serious, you can opt to throw an application exception, but this is not recommended unless you are sure of the cause and the effects of the exception on the subsystem. In most cases, throwing an EJBException is preferred.