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

计划的代码重用范围：这里的问题是您是打算把日志代码添加到多个地方，还是打算重新设计、重新构造代码来减少日志代码。

您要为之服务的客户机的类型：考虑您是将为 J2EE Web 层、单机 Java 应用程序、PDA 还是将为其它客户机服务是很重要的。Web 层设计有各种形状和大小。如果您在使用命令（Command）模式，在这个模式中，Web 层通过每次传入一个不同的命令调用 EJB 层中的相同方法，那么，把异常记录到命令在其中执行的 EJB 组件中是很有用的。在多数其它的 Web 层设计中，把异常记录到 Web 层本身要更容易，也更好，因为您需要把异常日志代码添加到更少的地方。如果您的 Web 层和 EJB 层在同一地方并且不需要支持任何其它类型的客户机，那么就应该考虑后一种选择。

您将处理的异常的类型（应用程序或系统）：处理应用程序异常与处理系统异常有很大不同。系统异常的发生不受 EJB 开发者意图的控制。因为系统异常的含义不清楚，所以内容应指明异常的上下文。您已经看到了，通过对原始异常进行包装使这个问题得到了最好的处理。另一方面，应用程序异常是由 EJB 开发者显式抛出的，通常包装有一条消息。因为应用程序异常的含义清楚，所以没有理由要保护它的上下文。这种类型的异常不必记录到 EJB 层或客户机层；它应该以一种有意义的方式提供给最终用户，带上指向所提供的解决方案的另一条备用途径。系统异常消息没必要对最终用户很有意义。

处理应用程序异常

在这一部分及其后的几个部分中，我们将更仔细地研究用 EJB 异常处理应用程序异常和系统异常，以及 Web 层设计。作为这个讨论的一部分，我们将探讨处理从会话和实体 EJB 组件抛出的异常的不同方式。

实体 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 组件一般是哑类，它们的唯一职责就是创建

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