【IT168技术文档】 
    随着 J2EE 成为企业开发平台之选，越来越多基于 J2EE 的应用程序将投入生产。J2EE 平台的重要组件之一是 Enterprise JavaBean（EJB）API。J2EE 和 EJB 技术一起提供了许多优点，但随之而来的还有一些新的挑战。特别是企业系统，其中的任何问题都必须快速得到解决。在本文中，企业 Java 编程老手 Srikanth Shenoy 展现了他在 EJB 异常处理方面的非常好的做法，这些做法可以更快解决问题。 

    在 hello-world 情形中，异常处理非常简单。每当碰到某个方法的异常时，就捕获该异常并打印堆栈跟踪或者声明这个方法抛出异常。不幸的是，这种办法不足以处理现实中出现的各种类型的异常。在生产系统中，当有异常抛出时，很可能是最终用户无法处理他或她的请求。当发生这样的异常时，最终用户通常希望能这样： 

    有一条清楚的消息表明已经发生了一个错误 

    有一个唯一的错误号，他可以据此访问可方便获得的客户支持系统 

    问题快速得到解决，并且可以确信他的请求已经得到处理，或者将在设定的时间段内得到处理。 

    理想情况下，企业级系统将不仅为客户提供这些基本的服务，还将准备好一些必要的后端机制。举例来说，客户服务小组应该收到即时的错误通知，以便在客户打电话求助之前服务代表就能意识到问题。此外，服务代表应该能够交叉引用用户的唯一错误号和产品日志，从而快速识别问题 — 最好是能把问题定位到确切的行号或确切的方法。为了给最终用户和支持小组提供他们需要的工具和服务，在构建一个系统时，您就必须对系统被部署后可能出问题的所有地方心中有数。 

    在本文中，我们将谈谈基于 EJB 的系统中的异常处理。我们将从回顾异常处理的基础知识开始，包括日志实用程序的使用，然后，很快就转入对 EJB 技术如何定义和管理不同类型的异常进行更详细的讨论。此后，我们将通过一些代码示例来研究一些常见的异常处理解决方案的优缺点，我还将展示我自己在充分利用 EJB 异常处理方面的非常好的做法。 

    请注意，本文假设您熟悉 J2EE 和 EJB 技术。您应理解实体 bean 和会话 bean 的差异。如果您对 bean 管理的持久性（bean-managed persistence（BMP））和容器管理的持久性（container-managed persistence（CMP））在实体 bean 上下文中是什么意思稍有了解，也是有帮助的。请参阅参考资料部分了解关于 J2EE 和 EJB 技术的更多信息。 

    异常处理基础知识 

    解决系统错误的第一步是建立一个与生产系统具有相同构造的测试系统，然后跟踪导致抛出异常的所有代码，以及代码中的所有不同分支。在分布式应用程序中，很可能是调试器不工作了，所以，您可能将用 System.out.println() 方法跟踪异常。System.out.println 尽管很方便，但开销巨大。在磁盘 I/O 期间，System.out.println 对 I/O 处理进行同步，这极大降低了吞吐量。在缺省情况下，堆栈跟踪被记录到控制台。但是，在生产系统中，浏览控制台以查看异常跟踪是行不通的。而且，不能保证堆栈跟踪会显示在生产系统中，因为，在 NT 上，系统管理员可以把 System.out 和 System.err 映射到 ' '，在 UNIX 上，可以映射到 dev/null。此外，如果您把 J2EE 应用程序服务器作为 NT 服务运行，甚至不会有控制台。即使您把控制台日志重定向到一个输出文件，当产品 J2EE 应用程序服务器重新启动时，这个文件很可能也将被重写。 

    异常处理的原则 

    以下是一些普遍接受的异常处理原则：
　　☆ 如果无法处理某个异常，那就不要捕获它。
　　☆ 如果捕获了一个异常，请不要胡乱处理它。
　　☆ 尽量在靠近异常被抛出的地方捕获异常。
　　☆ 在捕获异常的地方将它记录到日志中，除非您打算将它重新抛出。
　　☆ 按照您的异常处理必须多精细来构造您的方法。
　　☆ 需要用几种类型的异常就用几种，尤其是对于应用程序异常。 

    第 1 点显然与第 3 点相抵触。实际的解决方案是以下两者的折衷：您在距异常被抛出多近的地方将它捕获；在完全丢失原始异常的意图或内容之前，您可以让异常落在多远的地方。 

    注：尽管这些原则的应用遍及所有 EJB 异常处理机制，但它们并不是特别针对 EJB 异常处理的。 

    由于以上这些原因，把代码组装成产品并同时包含 System.out.println 并不是一种选择。在测试期间使用 System.out.println，然后在形成产品之前除去 System.out.println 也不是上策，因为这样做意味着您的产品代码与测试代码运行得不尽相同。您需要的是一种声明控制日志机制，以使您的测试代码和产品代码相同，并且当记录日志以声明方式关闭时，给产品带来的性能开销最小。 

    这里的解决方案显然是使用一个日志实用程序。采用恰当的编码约定，日志实用程序将负责精确地记录下任何类型的消息，不论是系统错误还是一些警告。所以，我们将在进一步讲述之前谈谈日志实用程序。 

    日志领域：鸟瞰 

    每个大型应用程序在开发、测试及产品周期中都使用日志实用程序。在今天的日志领域中，有几个角逐者，其中有两个广为人知。一个是 Log4J，它是来自 Apache 的 Jakarta 的一个开放源代码的项目。另一个是 J2SE 1.4 捆绑提供的，它是最近刚加入到这个行列的。我们将使用 Log4J 说明本文所讨论的非常好的做法；但是，这些非常好的做法并不特别依赖于 Log4J。 

    Log4J 有三个主要组件：layout、appender 和 category。Layou 代表消息被记录到日志中的格式。appender 是消息将被记录到的物理位置的别名。而 category 则是有名称的实体：您可以把它当作是日志的句柄。layout 和 appender 在 XML 配置文件中声明。每个 category 带有它自己的 layout 和 appender 定义。当您获取了一个 category 并把消息记录到它那里时，消息在与该 category 相关联的各个 appender 处结束，并且所有这些消息都将以 XML 配置文件中指定的 layout 格式表示。 

    Log4J 给消息指定四种优先级：它们是 ERROR、WARN、INFO 和 DEBUG。为便于本文的讨论，所有异常都以具有 ERROR 优先级记录。当记录本文中的一个异常时，我们将能够找到获取 category（使用 Category.getInstance(String name) 方法）的代码，然后调用方法 category.error()（它与具有 ERROR 优先级的消息相对应）。 

    尽管日志实用程序能帮助我们把消息记录到适当的持久位置，但它们并不能根除问题。它们不能从产品日志中精确找出某个客户的问题报告；这一便利技术留给您把它构建到您正在开发的系统中。 

    要了解关于 Log4J 日志实用程序或 J2SE 所带的日志实用程序的更多信息，请参阅参考资料部分。 

    异常的类别 

    异常的分类有不同方式。这里，我们将讨论从 EJB 的角度如何对异常进行分类。EJB 规范将异常大致分成三类： 

    JVM 异常：这种类型的异常由 JVM 抛出。OutOfMemoryError 就是 JVM 异常的一个常见示例。对 JVM 异常您无能为力。它们表明一种致命的情况。唯一得体的退出办法是停止应用程序服务器（可能要增加硬件资源），然后重新启动系统。 

    应用程序异常：应用程序异常是一种定制异常，由应用程序或第三方的库抛出。这些本质上是受查异常（checked exception）；它们预示了业务逻辑中的某个条件尚未满足。在这样的情况下，EJB 方法的调用者可以得体地处理这种局面并采用另一条备用途径。 
    
    系统异常：在大多数情况下，系统异常由 JVM 作为 RuntimeException 的子类抛出。例如，NullPointerException 或 ArrayOutOfBoundsException 将因代码中的错误而被抛出。另一种类型的系统异常在系统碰到配置不当的资源（例如，拼写错误的 JNDI 查找（JNDI lookup））时发生。在这种情况下，系统就将抛出一个受查异常。捕获这些受查系统异常并将它们作为非受查异常（unchecked exception）抛出颇有意义。最重要的规则是，如果您对某个异常无能为力，那么它就是一个系统异常并且应当作为非受查异常抛出。 

    注：受查异常是一个作为 java.lang.Exception 的子类的 Java 类。通过从 java.lang.Exception 派生子类，就强制您在编译时捕获这个异常。相反地，非受查异常则是一个作为 java.lang.RuntimeException 的子类的 Java 类。从 java.lang.RuntimeException 派生子类确保了编译器不会强制您捕获这个异常。