EJB异常处理的最佳做法 - 编程入门网

public Object ejbCreate(OrderValue val) throws CreateException { 　　 try { 　　　　 if (value.getItemName() == null) { 　　　　　 throw new CreateException("Cannot create Order without a name"); 　　　　 } 　　　　 String custId = val.getCustomerId(); 　　　　 Customer cust = customerHome.fingByPrimaryKey(custId); 　　　　 this.customer = cust; 　　 } catch (FinderException ne) { 　　 　　　 //How do you handle this Exception ? 　　 } catch (RemoteException re) { 　　　 //This is clearly a System Exception 　　　 throw ExceptionLogUtil.createLoggableEJBException(re); 　　 } 　　 return null; }

虽然没有什么东西阻止您把 FinderException 当应用程序异常对待，但把它当系统异常对待会更好。原因是：EJB 客户机倾向于把 EJB 组件当黑箱对待。如果 createOrder() 方法的调用者获得了一个 FinderException ，这对调用者并没有任何意义。OrderEJB 正试图设置客户远程引用这件事对调用者来说是透明的。从客户机的角度看，失败仅仅意味着该订单无法创建。

这类情形的另一个示例是，会话 EJB 组件试图创建另一个会话 EJB，因而导致了一个 CreateException 。一种类似的情形是，实体 EJB 方法试图创建一个会话 EJB 组件，因而导致了一个 CreateException 。这两个异常都应该当作系统异常对待。

另一个可能碰到的挑战是会话 EJB 组件在它的某个容器回调方法中获得了一个 FinderException 。您必须逐例处理这类情况。您可能要决定是把 FinderException 当应用程序异常还是系统异常对待。请考虑清单 1 的情况，其中调用者调用了会话 EJB 组件的 deleteOldOrder 方法。如果我们不是捕获 FinderException ，而是将它抛出，会怎么样呢？在这一特定情况中，把 FinderException 当系统异常对待似乎是符合逻辑的。这里的理由是，会话 EJB 组件倾向于在它们的方法中做许多工作，因为它们处理工作流情形，并且它们对调用者而言是黑箱。

另一方面，请考虑会话 EJB 正在处理下订单的情形。要下一个订单，用户必须有一个简档 ― 但这个特定用户却还没有。业务逻辑可能希望会话 EJB 显式地通知用户她的简档丢失了。丢失的简档很可能表现为会话 EJB 组件中的 javax.ejb.ObjectNotFoundException （ FinderException 的一个子类）。在这种情况下，最好的办法是在会话 EJB 组件中捕获 ObjectNotFoundException 并抛出一个应用程序异常，让用户知道她的简档丢失了。

即使是有了很好的异常处理策略，另一个问题还是经常会在测试中出现，而且在产品中也更加重要。编译器和运行时优化会改变一个类的整体结构，这会限制您使用堆栈跟踪实用程序来跟踪异常的能力。这就是您需要代码重构的帮助的地方。您应该把大的方法调用分割为更小的、更易于管理的块。而且，只要有可能，异常类型需要多少就划分为多少；每次您捕获一个异常，都应该捕获已规定好类型的异常，而不是捕获所有类型的异常。

结束语

我们已经在本文讨论了很多东西，您可能想知道我们已经讨论的主要设计是否都物有所值。我的经验是，即便是在中小型项目中，在开发周期中，您的付出就已经能看到回报，更不用说测试和产品周期了。此外，在宕机对业务具有毁灭性影响的生产系统中，良好的异常处理体系结构的重要性再怎么强调也不过分。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!