较新的Java API（比如Spring Framework和Java Data Object库）很少或根本不依赖于已检查异常。Hibernate ORM framework从release 3.0起重新定义了关键设备，以免于使用已检查异常。这反映了由这些框架报告的绝大部分异常异常条件是不可恢复的，这些异常源于方法调用的不正确编码或数 据库服务器失效等基本组件原因。实际上，强制调用者去捕捉或声明这样异常几乎没有任何益处。

　　架构中的错误处理

　　在架构中有效处理错误的第一步是承认处理错误的必要性。承认这一点对于工程师来说有困难，因为他们认为自己有能力创造无缺陷的软件，并引以为豪。下面这些 理由可能有所帮助。首先，应用程序开发会在常见错误上花费大量的时间。提供程序员产生的错误将使团队诊断和修复这些错误变得十分简单。第二，对于错误异常 条件过度使用Java库中的已检查异常将强制代码来处理这些错误，即使调用顺序完全正确。如果没有适当的错误处理框架，由此产生的暂时异常处理将向应用程 序中插入平均信息量。

　　成功的错误处理框架必须达到四个目标：

　　● 使代码混乱最小化

　　● 捕捉并保留诊断信息

　　● 通知合适的人员

　　● 比较得体地退出活动

　　错误会分散应用程序的真正目的。因此，用于错误处理的代码数量应当最小化，并在理想情况下，应与程序的语义部分隔离。错误处理必须满足纠错人员 的需要。他们需要知道是否发生错误并且获取相关信息以判断错误原因。尽管从定义上说，错误不可恢复，但可靠的错误处理措施将以得体地方式终结出现错误的活 动。

　　对于错误异常条件使用未检查异常

　　有许多原因使我们做出使用未检查异常表示错误异常条件的架构性决定。作为对编程错误的回报，Java运行时将抛出RuntimeException的子类 （比如ArithmeticException和ClassCastException），针对架构设定先例。未检查异常使上游方法摆脱了包含无关代码的 要求，从而最大限度地减少了混乱。

　　错误处理策略应当承认Java库和其他API中的方法可能使用已检查异常来表示应用程序环境下的错误异常条件。在这种情况下，采用架构惯例在其出现的地方捕捉API异常，将它作为错误，并抛出未检查异常来说明错误异常条件并捕捉诊断信息。

　　在这种情况下抛出的特定异常类型应当由架构本身定义。不要忘记错误异常的主要目的是传达诊断信息并记录，以帮助开发人员发现问题产生的原因。使 用多错误异常类型可能有些过度，因为架构会对它们进行完全相同的处理。在绝大多数情况下，把良好的描述性文本消息嵌入到单独的错误类型中，便可完成此项工 作。使用Java的一般RuntimeException来表示错误条件很容易进行防御。从Java 1.4时起，RuntimeException同其他throwable类一样，支持异常处理链式机制，允许设计人员捕捉并报告导致错误的已检查异常。

　　设计人员可以定义自己的未检查异常进行报告错误。如果需要使用不支持异常链接机制的Java 1.3或更早版本，这一步是必需的。实现相似的链接功能去捕捉并转换引起应用程序错误的异常相当简单。在错误报告异常中，应用程序可能需要特别的行为。这 可能是为架构创建RuntimeException子类的另一个原因。

　　建立错误屏障

　　决定哪些异常要抛出以及何时抛出将成为错误处理框架的重要决定。同样重要的问题是何时捕捉错误异常及其后如何做。这里的目标是使应用程序的功能部分从处理错误的职责中分离出来。关注点分离通常是比较好的做法。负责处理错误的中央设备将为您带来很多的好处。

　　在错误屏障（fault barrier）模式下，任何应用程序组件都可以抛出错误异常，但只有作为“错误屏障”的组件才可以捕捉到错误异常。开发人员为了处理错误问题在应用程序 中插入了大量复杂代码，而采用此模式可消除大部分此类代码。从逻辑上讲，错误屏障存在于靠近调用堆栈的顶端。在这里，它可以阻断异常向上传播，以避免触发 默认动作。默认动作根据应用程序类型的不同而不同。对于独立的Java应用程序来说，默认动作意味着终止活动线程。对于驻留在应用服务器上的Web应用程 序，默认动作意味着应用服务器会向浏览器发送不友好的（且令人为难的）响应。

　　错误屏障组件的首要职责是记录包含在错误异常中的信息，以便进行下一步行动。应用程序日志是迄今为止做这件事情最理想的方法。异常的链信息、堆 栈跟踪等对于诊断专家来说都是有价值的信息。发送错误信息最差的地方是通过用户界面。将客户牵涉到应用程序的排错过程中，将对开发人员或客户没有任何益 处。如果开发人员真的把诊断信息添加到了用户界面上，这说明开发人员的记录策略需要改进。