J2EE中的异常管理及错误跟踪

　　回顾一下你上一个J2EE工程，是否遇到过类似错误没有记入日志或者被多次记录的情况?是否只是因为在某处代码吃掉了异常导致你花费无数次时间来跟踪一个bug?是否你的用户直接看到了堆栈的跟踪信息?如果这样的话，你可能需要一种通用的异常管理的策略和一些补充的代码。这篇文章为你提供了在J2EE项目中通过使用错误处理框架使用一些策略的基础。

　　Java中关于异常处理的争论可以被认为是一种信仰上的争执:一方面，强制异常(checked exceptions)的支持者认为调用者应该处理他们调用代码出现的异常;另一方面，非强制(unchecked exceptions)异常的追随者认为强制异常混乱了代码，而且通常客户端不能立即处理，那为什么还要检查他呢。

　　作为初级工程师，我们首先信奉的是强制异常，但几年后，在使用N久的try/catch/finally后，我们开始转向非强制异常了。因为我们开始相信一些处理错误状况的基本规则:

　　如果需要处理异常，那么就处理
　　如果处理不了，就抛出
　　如果抛不了，就用非强制的基类异常包装后再抛出

　　但这些异常被抛到最顶层时会怎么样呢?对这种情况，我们有一个底线确保错误信息被记录并且用户得到正确的提示。

　　本文提供了另外一种框架来处理异常，它扩展了“Create an Application-Wide User Session for J2EE”所提出的企业应用session工具。使用此框架的J2EE应用将:

　　总是向用户提供有意义的错误信息
　　记下未处理的错误环境，并且只记录一次
　　在日志文件中用唯一的请求ID号对异常进行编号，以便进行高精度的调试
　　在各层中设置一个强壮的、可扩展的，而又简单的策略来处理异常

　　为了搭建框架，我们运用了面向状态编程(AOP，aspect-oriented programming)、设计模式和使用XDoclet进行代码生成。

　　为什么我们需要通用的错误处理方法

　　在项目的开始，我们会做一些关键性的系统架构决定，如:系统中的元素如何交互?会话状态保存在哪儿?哪种通信协议会被使用等等。但这里并没有包含错误处理。因而每个开发人员都可以任意决定如何定义、分类、建模和处理错误。作为一个开发人员，你可以想象在这种方式下的结果:

　　1. 臃肿的日志:每个try/catch都包含log语句，这导致被污染的代码生成臃肿和多余的日志入口。
　　2. 多余的实现:同一类型的错误有不同的表示，这导致处理的复杂化。
　　3. 破碎的封装:来自其他组件的异常被定义为方法标识的一部分，这导致接口和实现的分离被打破了。
　　4. 不明确的异常定义:方法签名通常采用抛出java.lang.Exception，这导致客户端不能明确得到方法错误的语义。

　　通常没有定义异常处理策略的借口是:java已经提供了异常处理。这是事实，java也提供一贯的定义、通信、传播及响应异常的工具。但开发人员需要决定如何在实际的项目中使用这些服务。几个方面是必须要考虑的，如:

　　1. 检查或不检查异常:是否应该检查或不检查新异常类?
　　2. 异常的使用者:究竟是谁需要知道什么时候会发生未处理的异常及由谁来负责记录及通知操作人员?
　　3. 基础的异常层次:异常需要包含什么信息及异常层次需要反映什么语义?
　　4. 传递;是否未处理的异常会被定义或传递给别的异常类，及他们如何在分布式环境中传递?
　　5. 解释:未处理的异常如何被解释为可阅读的，甚至支持多语言的信息?

　　在框架中封装规则，要快!

　　我们给出的通用异常处理策略是基于如下的因素:

　　使用非强制的异常:使用强制异常，调用者要被迫处理他们几乎不能处理的错误。非强制的异常则给调用者一个选择。在使用第三方类库时，你不能控制异常是强制或非强制的。这种情况下，你需要用非强制异常来包含强制异常。在使用非强制异常时，最大的让步是你不能再强制调用者来处理异常了。然而作为接口定义的一部分，异常仍是约定的关键部分并且继续成为Javadoc文档的一部分。

　封装异常处理并在每一层的顶层提供处理器:你可以专注于只处理业务逻辑相关的异常。处理器可以为特定层剩余的异常执行标准操作:记录日志、系统管理提示及转换等等。

　　通过“简单生活”方式来建模异常类层次:不要在发现新的错误类型时就创建新的异常类。首先问一下是否可以作为其他类型的变体来对待或者调用者确实需要捕获。记住异常至少在某方面是可以用他的属性来为不同的状况建立变化模型的对象。较少的异常类在开始时是足够的，但也仅在这种情况下可能需要用特定属性来处理。

　　提供有意义的信息给使用者:未处理的异常代表不可预知的事件和问题。告诉用户并且保存细节给技术支持人员。

　　虽然在不同的项目中需求、限制、异常层次及通知机制会有所不同，但许多元素还是一致的。因此为什么不完全地通过框架实现通用的策略呢?依据简单使用原则的框架是强制使用策略的最好方法。通过jar文件与javadoc之类的可执行工件与开发人员对话比白纸和幻灯片更容易表示架构准则。

　　然而，你不能要求开发团队直到异常处理策略及附加的框架支持准备完毕后才开始错误处理。错误处理必须在第一个源文件创建时确定。一个好的启动方法是定义基础的异常层次。

　　基础异常层次

　　我们首要的任务是定义一个可以跨项目的通用异常层次。这里的非强制异常基类是UnrecoverableException，由于历史原因，这个名字可能会有些误导。你可以在自己的层次中使用更好的名字

　　当你不想使用强制异常时WrappedException可以提供一种简单通用的传送机制:包裹原来的异常并重新抛出。WrappedException保存原始异常作为内部引用，这使得当类需要原始异常时也可以可以正常工作。当这不重要时，你可以使用SerializableException，他类似于WrappedException，此外还可以在客户端没有对类库作任何假设的情况下使用。

　　虽然我们偏好和推荐非强制异常，但你可以保留强制异常作为可选项。InstrumentedException是一个支持强制非强制异常的接口，他遵循一定属性实现模式。他允许异常处理者一致地检查来源页不需要考虑是来自强制或非强制的异常。

　　下面的类图显示了我们基础的异常层次。

　　这时候我们已经拥有了一个策略及相应的一组可以被抛出的异常。现在是时候建立安全网了。

　　防守的底线

　　“创建应用范围的用户会话”这篇文章描述了Rampart，一个使用了由企业信息系统层，基于无状态会话bean的业务层及基于网页和标准J2SE客户端的客户层的分层架构。异常可以从任意层次抛出，可以在线处理或者延迟到调用链的最终端。J2SE和J2EE应用服务器都可以通过捕获未处理的Errors和RuntimeExceptions来抵御侵入性的行为，通过输出栈信息、记入日志或者执行其他默认的操作。在任何情况下，用户都不应该看到输出信息，通常是没有意义的甚至影响程序稳定性的错误。因此我们必须构建自己的壁垒来提供更好的异常处理机制来维持这一防守的底线。看一下图2: