摘要
回顾一下你上一个J2EE工程，是否碰到过类似错误没有记入日志或者被多次记录的情况？是否只是因为在某处代码吃掉了异常导致你花费无数次时间来跟踪一个bug?是否你的用户直接看到了堆栈的跟踪信息？假如这样的话，你可能需要一种通用的异常治理的策略和一些补充的代码。这篇文章为你提供了在J2EE项目中通过使用错误处理框架使用一些策略的基础。(3100个英文单词，2005年7月11日)
java中关于异常处理的争论可以被认为是一种信仰上的争执：一方面，强制异常(checked exceptions)的支持者认为调用者应该处理他们调用代码出现的异常；另一方面，非强制(unchecked exceptions)异常的追随者认为强制异常混乱了代码，而且通常客户端不能立即处理，那为什么还要检查他呢。
作为初级工程师，我们首先信仰的是强制异常，但几年后，在使用N久的try/catch/finally后，我们开始转向非强制异常了。因为我们开始相信一些处理错误状况的基本规则：
假如需要处理异常，那么就处理
假如处理不了，就抛出
假如抛不了，就用非强制的基类异常包装后再抛出
但这些异常被抛到最顶层时会怎么样呢？对这种情况，我们有一个底线确保错误信息被记录并且用户得到正确的提示。
本文提供了另外一种框架来处理异常，它扩展了“Create an application-Wide User session for J2EE”(JavaWorld, 2005年3月)所提出的企业应用session工具。使用此框架的J2EE应用将：
总是向用户提供有意义的错误信息
记下未处理的错误环境，并且只记录一次
在日志文件中用唯一的请求ID号对异常进行编号，以便进行高精度的调试
在各层中设置一个强壮的、可扩展的，而又简单的策略来处理异常
为了搭建框架，我们运用了面向状态编程(AOP，aspect-oriented PRogramming)、设计模式和使用XDoclet进行代码生成。
你可以在资源中找到所有代码及一个使用框架的J2EE应用。这些源程序组成了一个名为Rampart的完整框架，当初是为丹麦哥本哈根基于J2EE的电子保健系统应用(EHR, electronic healthcare records)而开发的。
为什么我们需要通用的错误处理方法
在项目的开始，我们会做一些要害性的系统架构决定，如：系统中的元素如何交互？会话状态保存在哪儿？哪种通信协议会被使用等等。但这里并没有包含错误处理。因而每个开发人员都可以任意决定如何定义、分类、建模和处理错误。作为一个开发人员，你可以想象在这种方式下的结果：
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:
异常可能发生在EJB层的服务端和网页层，甚至独立的客户端。在第一种情况下，异常停留在同一VM中，也可能被传送到网页层。这儿就是我们要安装的顶层异常处理器的地方。
在后一种情况下，异常发生在EJB容器的边缘并且通过RMI连接传递到客户端。必须注重不要传送任何属于服务端类的异常（如来自对象关系映射框架这类的）到客户端。而由EJB异常处理器通过使用SerializableException作为中介来处理这个问题。在客户端，顶层的Swing异常处理器捕捉其他未处理的错误并采取相应措施。
异常处理框架
在Rampart框架中异常处理器是一个实现了ExceptionHandler接口的类。这个接口仅有一个包含两个参数（待处理的Throwable和当前的Thread）的方法。方便起见，框架提供了包含基本的实现类ExceptionHandlerBase，他辨别Throwable并将其代理给RuntimeException, Error, Throwable和Rampart框架的Unrecoverable的特定的抽象方法来处理。子类提供这些方法的实现并区别处理。
下面的类图显示了异常处理器的层次和三个缺省的异常处理器。
