EJB 异常处理的最佳做法（2）
实体 EJB 组件中的应用程序异常
清单 2 显示了实体 EJB 的一个 ejbCreate() 方法。这个方法的调用者传入一个 OrderItemValue 并请求创建一个 OrderItem 实体。因为 OrderItemValue 没有名称，所以抛出了 CreateException。
清单 2. 实体 EJB 组件中的样本 ejbCreate() 方法
public Integer ejbCreate(OrderItemValue value) throws CreateException {
if (value.getItemName() == null) {
throw new CreateException("Cannot create Order without a name");
}
..
..
return null;
}
清单 2 显示了 CreateException 的一个很典型的用法。类似地，假如方法的输入参数的值不正确，则查找程序方法将抛出 FinderException。
然而，假如您在使用容器治理的持久性（CMP），则开发者无法控制查找程序方法，从而 FinderException 永远不会被 CMP 实现抛出。尽管如此，在 Home 接口的查找程序方法的 throws 子句中声明 FinderException 还是要更好一些。RemoveException 是另一个应用程序异常，它在实体被删除时被抛出。
从实体 EJB 组件抛出的应用程序异常基本上限定为这三种类型（CreateException、FinderException 和 RemoveException）及它们的子类。多数应用程序异常都来源于会话 EJB 组件，因为那里是作出智能决策的地方。实体 EJB 组件一般是哑类，它们的唯一职责就是创建和取回数据。
会话 EJB 组件中的应用程序异常
清单 3 显示了来自会话 EJB 组件的一个方法。这个方法的调用者设法订购 n 件某特定类型的某商品。SessionEJB() 方法计算出仓库中的数量不够，于是抛出 NotEnoughStockException。NotEnoughStockException 适用于特定于业务的场合；当抛出了这个异常时，调用者会得到采用另一个备用途径的建议，让他订购更少数量的商品。
清单 3. 会话 EJB 组件中的样本容器回调方法
public ItemValueObject[] placeOrder(int n, ItemType itemType) throws
NotEnoughStockException {
//Check Inventory.
Collection orders = ItemHome.findByItemType(itemType);
if (orders.size() < n) {
throw NotEnoughStockException("Insufficient stock for " + itemType);
}
}
处理系统异常
系统异常处理是比应用程序异常处理更为复杂的论题。由于会话 EJB 组件和实体 EJB 组件处理系统异常的方式相似，所以，对于本部分的所有示例，我们都将着重于实体 EJB 组件，不过请记住，其中的大部分示例也适用于处理会话 EJB 组件。
当引用其它 EJB 远程接口时，实体 EJB 组件会碰到 RemoteException，而查找其它 EJB 组件时，则会碰到 NamingException，假如使用 bean 治理的持久性（BMP），则会碰到 SQLException。与这些类似的受查系统异常应该被捕捉并作为 EJBException 或它的一个子类抛出。原始的异常应被包装起来。清单 4 显示了一种处理系统异常的办法，这种办法与处理系统异常的 EJB 容器的行为一致。通过包装原始的异常并在实体 EJB 组件中将它重新抛出，您就确保了能够在想记录它的时候访问该异常。
清单 4. 处理系统异常的一种常见方式
try {
OrderHome orderHome = EJBHomeFactory.getInstance().getOrderHome();
Order order = orderHome.findByPrimaryKey(Integer id);
} catch (NamingException ne) {
throw new EJBException(ne);
} catch (SQLException se) {
throw new EJBException(se);
} catch (RemoteException re) {
throw new EJBException(re);
}
避免重复记录
通常，异常记录发生在会话 EJB 组件中。但假如直接从 EJB 层外部访问实体 EJB 组件，又会怎么样呢？要是这样，您就不得不在实体 EJB 组件中记录异常并抛出它。这里的问题是，调用者没办法知道异常是否已经被记录，因而很可能再次记录它，从而导致重复记录。更重要的是，调用者没办法访问初始记录时所生成的唯一的标识。任何没有交叉引用机制的记录都是毫无用处的。
请考虑这种最糟糕的情形：单机 Java 应用程序访问了实体 EJB 组件中的一个方法 foo()。在一个名为 bar() 的会话 EJB 方法中也访问了同一个方法。一个 Web 层客户机调用会话 EJB 组件的方法 bar() 并也记录了该异常。假如当从 Web 层调用会话 EJB 方法 bar() 时在实体 EJB 方法 foo() 中发生了一个异常，则该异常将被记录到三个地方：先是在实体 EJB 组件，然后是在会话 EJB 组件，最后是在 Web 层。而且，没有一个堆栈跟踪可以被交叉引用！
