回顾一下你上一个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文档的一部分。
