【IT168技术文档】 
    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。 

    常见的异常处理策略 

    如果没有异常处理策略，项目小组的不同开发者很可能会编写以不同方式处理异常的代码。由于同一个异常在系统的不同地方可能以不同的方式被描述和处理，所以，这至少会使产品支持小组感到迷惑。缺乏策略还会导致在整个系统的多个地方都有记录。日志应该集中起来或者分成几个可管理的单元。理想的情况是，应在尽可能少的地方记录异常日志，同时不损失内容。在这一部分及其后的几个部分，我将展示可以在整个企业系统中以统一的方式实现的编码策略。您可以从参考资料部分下载本文开发的实用程序类。 

    清单 1 显示了来自会话 EJB 组件的一个方法。这个方法删除某个客户在特定日期前所下的全部订单。首先，它获取 OrderEJB 的 Home 接口。接着，它取回某个特定客户的所有订单。当它碰到在某个特定日期之前所下的订单时，就删除所订购的商品，然后删除订单本身。请注意，抛出了三个异常，显示了三种常见的异常处理做法。（为简单起见，假设编译器优化未被使用。） 

    清单 1. 三种常见的异常处理做法

100 try ...{
101 OrderHome homeObj = EJBHomeFactory.getInstance().getOrderHome();
102 Collection orderCollection = homeObj.findByCustomerId(id);
103 iterator orderItter = orderCollection.iterator();
104 while (orderIter.hasNext()) ...{
105 Order orderRemote = (OrderRemote) orderIter.getNext();
106 OrderValue orderVal = orderRemote.getValue();
107 if (orderVal.getDate() < "mm/dd/yyyy") ...{
108 OrderItemHome itemHome =
EJBHomeFactory.getInstance().getItemHome();
109 Collection itemCol = itemHome.findByOrderId(orderId)
110 Iterator itemIter = itemCol.iterator();
111 while (itemIter.hasNext()) ...{
112 OrderItem item = (OrderItem) itemIter.getNext();
113 item.remove();
114 }
115 orderRemote.remove();
116 }
117 }
118 } catch (NamingException ne) ...{
119 throw new EJBException("Naming Exception occurred");
120 } catch (FinderException fe) ...{
121 fe.printStackTrace();
122 throw new EJBException("Finder Exception occurred");
123 } catch (RemoteException re) ...{
124 re.printStackTrace();
125 // Some code to log the message
126 throw new EJBException(re);
127 }

    现在，让我们用上面所示的代码来研究一下所展示的三种异常处理做法的缺点。 

    抛出／重抛出带有出错消息的异常 

    NamingException 可能发生在行 101 或行 108。当发生 NamingException 时，这个方法的调用者就得到 RemoteException 并向后跟踪该异常到行 119。调用者并不能告知 NamingException 实际是发生在行 101 还是行 108。由于异常内容要直到被记录了才能得到保护，所以，这个问题的根源很难查出。在这种情形下，我们就说异常的内容被“吞掉”了。正如这个示例所示，抛出或重抛出一个带有消息的异常并不是一种好的异常处理解决办法。 

    记录到控制台并抛出一个异常 

    FinderException 可能发生在行 102 或 109。不过，由于异常被记录到控制台，所以仅当控制台可用时调用者才能向后跟踪到行 102 或 109。这显然不可行，所以异常只能被向后跟踪到行 122。这里的推理同上。 

    包装原始的异常以保护其内容 

    RemoteException 可能发生在行 102、106、109、113 或 115。它在行 123 的 catch 块被捕获。接着，这个异常被包装到 EJBException 中，所以，不论调用者在哪里记录它，它都能保持完整。这种办法比前面两种办法更好，同时演示了没有日志策略的情况。如果 deleteOldOrders() 方法的调用者记录该异常，那么将导致重复记录。而且，尽管有了日志记录，但当客户报告某个问题时，产品日志或控制台并不能被交叉引用。