EJB 异常处理探试法
EJB 组件应抛出哪些异常？您应将它们记录到系统中的什么地方？这两个问题盘根错结、相互联系，应该一起解决。解决办法取决于以下因素：
- 您的 EJB 系统设计：在良好的 EJB 设计中，客户机绝不调用实体 EJB 组件上的方法。多数实体 EJB 方法调用发生在会话 EJB 组件中。如果您的设计遵循这些准则，则您应该用会话 EJB 组件来记录异常。如果客户机直接调用了实体 EJB 方法，则您还应该把消息记录到实体 EJB 组件中。然而，存在一个难题：相同的实体 EJB 方法可能也会被会话 EJB 组件调用。在这种情形下，如何避免重复记录呢？类似地，当一个会话 EJB 组件调用其它实体 EJB 方法时，您如何避免重复记录呢？很快我们就将探讨一种处理这两种情况的通用解决方案。（请注意，EJB 1.1 并未从体系结构上阻止客户机调用实体 EJB 组件上的方法。在 EJB 2.0 中，您可以通过为实体 EJB 组件定义本地接口规定这种限制。）
- 计划的代码重用范围：这里的问题是您是打算把日志代码添加到多个地方，还是打算重新设计、重新构造代码来减少日志代码。
- 您要为之服务的客户机的类型：考虑您是将为 J2EE Web 层、单机 Java 应用程序、PDA 还是将为其它客户机服务是很重要的。Web 层设计有各种形状和大小。如果您在使用命令（Command）模式，在这个模式中，Web 层通过每次传入一个不同的命令调用 EJB 层中的相同方法，那么，把异常记录到命令在其中执行的 EJB 组件中是很有用的。在多数其它的 Web 层设计中，把异常记录到 Web 层本身要更容易，也更好，因为您需要把异常日志代码添加到更少的地方。如果您的 Web 层和 EJB 层在同一地方并且不需要支持任何其它类型的客户机，那么就应该考虑后一种选择。
- 您将处理的异常的类型（应用程序或系统）：处理应用程序异常与处理系统异常有很大不同。系统异常的发生不受 EJB 开发者意图的控制。因为系统异常的含义不清楚，所以内容应指明异常的上下文。您已经看到了，通过对原始异常进行包装使这个问题得到了最好的处理。另一方面，应用程序异常是由 EJB 开发者显式抛出的，通常包装有一条消息。因为应用程序异常的含义清楚，所以没有理由要保护它的上下文。这种类型的异常不必记录到 EJB 层或客户机层；它应该以一种有意义的方式提供给最终用户，带上指向所提供的解决方案的另一条备用途径。系统异常消息没必要对最终用户很有意义。