EJB 异常处理的最佳做法（3）常见的异常处理策略

look_wt

常见的异常处理策略如果没有异常处理策略，项目小组的不同开发者很可能会编写以不同方式处理异常的代码。由于同一个异常在系统的不同地方可能以不同的方式被描述和处理，所以，这至少会使产品支持小组感到迷惑。缺乏策略还会导致在整个系统的多个地方都有记录。日志应该集中起来或者分成几个可管理的单元。理想的情况是，应在尽可能少的地方记录异常日志，同时不损失内容。在这一部分及其后的几个部分，我将展示可以在整个企业系统中以统一的方式实现的编码策略。您可以从 部分下载本文开发的实用程序类。      
清单 1 显示了来自会话 EJB 组件的一个方法。这个方法删除某个客户在特定日期前所下的全部订单。首先，它获取         OrderEJB 的 Home 接口。接着，它取回某个特定客户的所有订单。当它碰到在某个特定日期之前所下的订单时，就删除所订购的商品，然后删除订单本身。请注意，抛出了三个异常，显示了三种常见的异常处理做法。（为简单起见，假设编译器优化未被使用。）      
清单 1. 三种常见的异常处理做法

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

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() 方法的调用者记录该异常，那么将导致重复记录。而且，尽管有了日志记录，但当客户报告某个问题时，产品日志或控制台并不能被交叉引用。