Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Enterprise JavaBeans™ Specification, Version 2.0 - Sun Microsystems.pdf
Скачиваний:
14
Добавлен:
24.05.2014
Размер:
2.71 Mб
Скачать

Sun Microsystems Inc

Bean Provider’s responsibilities

Enterprise JavaBeans 2.0, Public Draft

Exception handling

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 (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 Subsections 9.6.8 and 11.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.

17.2.2 System exceptions

This 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 session or entity bean business method, a message-driven bean onMessage method, or a container callback method (e.g. ejbLoad).

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[26], unexpected RuntimeException, JVM errors, and so on.

If the enterprise bean method encounters a system-level exception or error that does not allow the method to successfully complete, 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[27] 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.

[26]Note that the enterprise bean business method may attempt to recover from a RemoteException. The text in this subsection applies only to the case when the business method does not wish to recover from the RemoteException.

[27]A checked exception is one that is not a subclass of java.lang.RuntimeException.

343

5/31/00