提供有用的信息

　　定义不同的错误报告异常类型没有任何道理，因为错误屏障会对它们进行同样的处理。意外事件异常差异很大，因为它们会向方法调用者传达各种条件。您的架构可能明确指定这些异常都应该扩展java.lang.Exception或指定的基类。

　　不要忘记这些异常是完整的Java类型，可以调整特定的字段、方法以及为特殊目的而构建的构造函数。例如，假想的 CheckingAccount processCheck()方法抛出的InsufficientFundsException类型可能包括OverdraftProtection对 象，此对象能够转移资金以弥补另一个账户的资金短缺，此账户的身份取决于设置核算账户的方式。

　　记录还是不记录

　　记录错误异常有实际意义是因为它们的目的是吸引开发人员去注意需要纠正的情况。但这并不适用于意外事件异常。它们可能代表相对少见的事件，但是在应用程序 的生命周期内，这些意外事件依然会发生。它们表明了如发生异常应用程序将按照其设计意图进行工作。按照惯例，在意外事件捕捉模块中加入记录代码只会增加混 乱代码而没有任何益处。如果意外事件表示重要事件，最好为方法产生一条记录项，用于在抛出意外事件异常并通知其调用者之前记录此事件。

　　异常方面

　　在面向方面编程（Aspect Oriented Programming (AOP)）中，错误和意外事件的处理是横切关注点。例如，要实现错误屏障模式，所有参与的类都必须遵守公共约定：

　　● 错误屏障方法必须驻留在遍历参与类的方法调用的头部。

　　● 它们都必须使用未检查异常来表示错误条件。

　　● 它们都必须使用特定的未检查异常类型，以便错误屏障能够接收到。

　　● 它们都必须从较低层方法中捕捉并转换已检查异常，这些异常在它们的执行环境中被视为错误。

　　● 它们不能干扰错误异常到屏障的传播。

　　这些关注点跨越了其他不相关类的边界。结果产生了少量分散错误处理代码并致使屏障类与参与者之间的隐式耦合（尽管对于完全没有使用模式来说是一 次重大改进）。AOP允许将错误处理关注点封装到应用于参与类的公共Aspect中。Java AOP框架（比如AspectJ和Spring AOP）把异常处理作为联接点，错误处理行为（或建议）能够附加到上面。这样，在错误屏障模式中绑定参与者的惯例就有所放宽。错误处理现在可以存在于独立 的非内联方面（out-of-line aspect）中，避免了将“屏障”方法置于方法调用序列的前面。

　　如果开发人员在架构中使用AOP，错误和意外事件的处理是方面在整个应用程序中应用的理想候选对象。完全探究错误和意外事件处理在AOP中如何运作，这是个令人感兴趣的话题，留作以后讨论。

　　结束语

　　尽管Java异常模型在其生命周期内已经引发了激烈的争论，但是当Java异常模型运用得当时，将会带来巨大的价值。作为架构师，应当决定如何 建立最大限度利用模型的惯例。思考一下错误和意外事件异常能够帮助开发人员做出正确的选择。Java异常模型使用得当，将保持应用程序的简洁性、可维护性 和正确性。把面向方面编程技术的错误和意外事件处理作为横切关注点，可为应用程序的架构带来某些明显的优势。