JAVA:EJB 的异常处理的最佳做法(2)

异常的类别

异常的分类有不同方式。这里，我们将讨论从 EJB 的角度如何对异常进行分类。EJB 规范将异常大致分成三类：

JVM 异常：这种类型的异常由 JVM 抛出。OutOfMemoryError 就是 JVM 异常的一个常见示例。对 JVM 异常您无能为力。它们表明一种致命的情况。唯一得体的退出办法是停止应用程序服务器（可能要增加硬件资源），然后重新启动系统。

应用程序异常：应用程序异常是一种定制异常，由应用程序或第三方的库抛出。这些本质上是受查异常（checked exception）；它们预示了业务逻辑中的某个条件尚未满足。在这样的情况下，EJB 方法的调用者可以得体地处理这种局面并采用另一条备用途径。

系统异常：在大多数情况下，系统异常由 JVM 作为 RuntimeException 的子类抛出。例如，NullPointerException 或 ArrayOutOfBoundsException 将因代码中的错误而被抛出。另一种类型的系统异常在系统碰到配置不当的资源（例如，拼写错误的 JNDI 查找（JNDI lookup））时发生。在这种情况下，系统就将抛出一个受查异常。捕获这些受查系统异常并将它们作为非受查异常（unchecked exception）抛出颇有意义。最重要的规则是，如果您对某个异常无能为力，那么它就是一个系统异常并且应当作为非受查异常抛出。

注：受查异常是一个作为 java.lang.Exception 的子类的 Java 类。通过从 java.lang.Exception 派生子类，就强制您在编译时捕获这个异常。相反地，非受查异常则是一个作为 java.lang.RuntimeException 的子类的 Java 类。从 java.lang.RuntimeException 派生子类确保了编译器不会强制您捕获这个异常。

EJB 容器怎样处理异常

EJB 容器拦截 EJB 组件上的每一个方法调用。结果，方法调用中发生的每一个异常也被 EJB 容器拦截到。EJB 规范只处理两种类型的异常：应用程序异常和系统异常。

EJB 规范把应用程序异常定义为在远程接口中的方法说明上声明的任何异常（而不是 RemoteException）。应用程序异常是业务工作流中的一种特殊情形。当这种类型的异常被抛出时，客户机会得到一个恢复选项，这个选项通常是要求以一种不同的方式处理请求。不过，这并不意味着任何在远程接口方法的 throws 子句中声明的非受查异常都会被当作应用程序异常对待。EJB 规范明确指出，应用程序异常不应继承 RuntimeException 或它的子类。

当发生应用程序异常时，除非被显式要求（通过调用关联的 EJBContext 对象的 setRollbackOnly() 方法）回滚事务，否则 EJB 容器就不会这样做。事实上，应用程序异常被保证以它原本的状态传送给客户机：EJB 容器绝不会以任何方式包装或修改异常。

系统异常被定义为受查异常或非受查异常，EJB 方法不能从这种异常恢复。当 EJB 容器拦截到非受查异常时，它会回滚事务并执行任何必要的清理工作。接着，它把该非受查异常包装到 RemoteException 中，然后抛给客户机。这样，EJB 容器就把所有非受查异常作为 RemoteException（或者作为其子类，例如 TransactionRolledbackException）提供给客户机。

对于受查异常的情况，容器并不会自动执行上面所描述的内务处理。要使用 EJB 容器的内部内务处理，您将必须把受查异常作为非受查异常抛出。每当发生受查系统异常（如 NamingException）时，您都应该通过包装原始的异常抛出 javax.ejb.EJBException 或其子类。因为 EJBException 本身是非受查异常，所以不需要在方法的 throws 子句中声明它。EJB 容器捕获 EJBException 或其子类，把它包装到 RemoteException 中，然后把 RemoteException 抛给客户机。

虽然系统异常由应用程序服务器记录（这是 EJB 规范规定的），但记录格式将因应用程序服务器的不同而异。为了访问所需的统计信息，企业常常需要对所生成的日志运行 shell/Perl 脚本。为了确保记录格式的统一，在您的代码中记录异常会更好些。

注：EJB 1.0 规范要求把受查系统异常作为 RemoteException 抛出。从 EJB 1.1 规范起规定 EJB 实现类绝不应抛出 RemoteException。