高效的Java异常处理
Java开发人员可以做出的最重要的架构性决策之一就是如何使用Java异常模型。Java异常一直以来就是社群中许多争议的靶子。有人争论到，在Java语言中的异常检查已是一场失败的试验。本文将辨析，失败的原因不在于Java异常模型，而在于Java类库的设计者未能充分了解到方法失败的两个基本原因。
本文倡导一种对异常条件本质的思考方式，并描述一些有助于设计的模式。最后，本文还将在AOP模型中，作为相互渗透的问题，来讨论异常的处理。当你能正确使用异常时，它们会有极大的好处。本文将帮助你做到这一点。
为何异常是如此重要
Java应用中的异常处理在很大程度上揭示了其所基于架构的强度。架构是在应用程序各个层次上所做出并遵循的决定。其中最重要的一个就是决定应用程序中的类，亚系统，或层之间沟通的方式。Java异常是Java方法将另类执行结果交流出去的方式，所以值得在应用架构中给予特殊关注。
一个衡量Java设计师水平和开发团队纪律性的好方法就是读读他们应用程序里的异常处理代码。首先要注意的是有多少代码用于捕获异常，写进日志文件，决定发生了什么，和在不同的异常间跳转。干净，简捷，关联性强的异常处理通常表明开发团队有着稳定的使用Java异常的方式。当异常处理代码的数量甚至要超过其他代码时，你可以看出团队之间的交流合作有很大的问题（可能在一开始就不存在），每个人都在用他们自己的方式来处理异常。
对突发异常的处理结果是可以预见的。如果你问问团队成员为什么异常会被抛出，捕获，或在特定的一处代码里忽视了异常的发生，他们的回答通常是，“我没有别的可做”。如果你问当他们编写的异常真的发生了会怎么样，他们会皱皱眉，你得到的回答类似于这样，“我不知道。我们从没测试过。”
你可以从客户端的代码判断一个java的组件是否有效利用了java的异常。如果它们包含着大堆的逻辑去弄清楚在何时一笔操作失败了，为何失败，是否有弥补的余地，那么原因很有可能要归咎于组件的报错设计。错误的报错系统会在客户端产生大量的“记录然后忘掉”的代码，这些代码鲜有用途。最差的是弄拧的逻辑，嵌套的try/catch/finally代码块，和一些其他的混乱而导致脆弱而难于管理的应用程序。
事后再来解决Java异常的问题，或根本就不解决，是软件项目产生混乱并导致滞后的主要原因。异常处理是一个在设计的各个部分都急需解决的问题。对异常处理建立一个架构性的约定是项目中首要做出的决定。合理使用Java异常模型对确保你的应用简单，易维护，和正确有着长远的影响。
解析异常
正确使用Java异常模型所包含的内容一直以来有着很大的争议。Java不是第一种支持异常算法语义的；但是，它却是第一种通过编译器来执行声明和处理某些异常的规则的语言。许多人都认为编译时的异常检查对精确的软件设计颇有帮助。图1显示的Java异常的等级。
图1：Java异常的等级
通常，Java编译器易做图抛出基于java.lang.Throwable的异常的方法要在它声明中的“throws”部分加上那个异常。而且，编译器还会证实客户端的方法或者捕获已声明的异常，或者特别声明自己也抛出同样的异常。这些简单的规则对世界范围的Java程序员都有深远的影响。
编译器放松了对Throwable继承树中两个分支的异常检查。java.long.Error和java.lang.RuntimeException 的子类免于编译时的检查。在这两类中，软件工程师通常对运行中异常更感兴趣。“不检查”的异常指的是这一组，以便和所有其它“检查”的异常区别开。
我可以想象那些接受“检查”的异常的人，也会很看重Java的数据类型。毕竟，编译器对数据类型施加的限制鼓励严格的编码和精确的思维。编译时的类型检查对减少运行时的严重问题有帮助。编译时的异常检查也能起到类似的作用，它会提醒开发人员某个方法可能会有预想不到的结果需要处理好。
早期的建议是尽可能的使用“检察的异常”，以此来最大限度的利用编译器提供的帮助来写出无错误的软件。Java类库API的设计者们都认同这一点，他们广泛地使用“检察的异常”来模拟类库方法中几乎所有的紧急应变措施。在J2SE5.1 API规格中，“检察的异常”类型已2比1的比率超过了“未检查的异常”类型。
对程序员而言，看上去在Java类库中大多数的常用方法对每一个可能的失败都声明了“检察的异常”。例如，java.io包
对IOException这个“检察的异常”就有着很大的依赖。至少有63个Java类库包，或直接，或通过十几个下面的子类，抛出这个异常。
I/O的失败极其稀有，但是却很严重。而且，一旦发生，从你所写的代码里基本上是无法补救的。Java程序员意识到他们不得不提供IOException或类似的不可补救的事件，而一个简单的Java类库方法的调用就可能让这些事件发生。捕获这些异常给本来简单的代码带来了一定的晦涩，因为即使在捕获的代码块里也基本上帮不上忙。但是不加以捕获又可能更糟糕，因为编译器要求你的方法必须要抛出那些异常。这样你的实施细则就不得不暴露在外了，而通常好的面向对象的设计都是要隐藏细节的。
这样一个不可能赢的局面导致了我们今天所警告的绝大多数臭名卓著的异常处理的颠覆性格局。同时也衍生了很多正确或错误的补救之道。
一些Java界的知名人物开始质疑Java的“检察的异常”的模型是否是一个失败的试验。有一些东西肯定是失败的，但是这和在Java语言里加入对异常的检查是毫无关联的。失败是由于在Java API的设计者们的思维里，大多数失败的情形是雷同的，所以可以通过同一种异常传达出去。
故障和应变
让我们来考虑在一个假想的银行应用中的CheckingAccount类。一个CheckingAcccount属于一个用户，记载着用户的存款余额，也能接受存款，接受止兑的通知，和处理汇入的支票。一个CheckingAcccount对象必须协调同步线程的访问，因为任何一个线程都可能改变它的状态。CheckingAcccount类里processCheck的方易做图接受一个Check对象为参数，通常从帐户余额里减去支票的金额。但是一个管理支票清算的用户端程序调用processCheck方法时，必须有两种可能的应变措施。一，CheckingAccount对象里可能对该支票已有一个止付的命令；二，帐户的余额可能不足已满足支票的金额。
所以，processCheck的方法对来自客户端的调用可以有3种方式回应。正常的是处理好支票，并把方法签名里声明的结果返回给调用方。两种应变的回应则是需要与支票清算端沟通的在银行领域实实在在存在的情况。processCheck方法所有3种返回结果都是按照典型的银行支票帐户的行为而精心设计的。
在Java里，一个自然的方法来表示上述紧急的应变是定义两种异常，比如StopPaymentException（止付异常）和 InsufficientFundsException（余额不足异常）。一个客户端如果忽略这些异常是不对的，因为这些异常在正常操作的情况下一定会被抛出。他们如同方法的签名一样反映了方法的全面行为。
客户端可以很容易的处理好这两种异常。如果对支票的兑付被停止了，客户端把该支票交付特别处理。如果是因为资金不足，用户端可以从用户的储蓄帐户里转移一些资金到支票帐户里，然后再试一次。
在使用CheckingAccount的API时，这些应变都是可以预计的和自然的结果。他们并不是意味着软件或运行环境的失败。这些异常和由于CheckingAccount类中一些内部实施细则引起的真正失败是不同的。
设想CheckingAccount对象在数据库里保持着一个恒定的状态，并使用JDBC API来对之访问。在那个API里，几乎所有的数据库访问方法都有可能因为和CheckingAccount实施无关的原因而失败。比如，有人可能忘了把数据库服务器运行起来，一个未有连上的网络数据线，访问数据库的密码改变了，等等。
JDBC依靠一种“检查的异常”，SQLException，来汇报任何可能的错误。可能出错的绝大多数原由都是数据库的配置，连接，或其所在的硬件设施。对processCheck方法而言，它对上述错误是无计可施的。这不应该，因为processCheck至少了解它自己的实施细则。在调用栈里上游的方法能处理这些问题的可能就更小。
CheckingAccount这个例子说明了一个方法不能成功返回它想要的结果的两个基本原因。这里是两个描述性的术语：
应变
与实际预料相符，一个方法给出另外一种回应，而这种回应可以表达成该方法所要达到的目的之一。这个方法的调用者预料到这个情况的出现，并有相对的应付之道。
故障
在未经计划的情况下，一个方法不能达到它的初衷，这是一个不诉诸该方法的实施细则就很难搞清的情况。
应用这些术语，对processCheck方法而言，一个止付的命令和一个超额的提取是两种可能的应变。而SQLException反映了可能的故障。processCheck方法的调用者应该能够提供应变，但却不一定能有效的处理好可能发生的故障。
Java异常的匹配
在建立应用架构中Java异常的规则时，以应变和故障的方式仔细考虑好“什么可能会出错”是有长远意义的。
条件
应变
故障
被考虑成
设计的一部分
一个糟糕的意外
预计到会发生
经常发生
绝不发生
关注方
上游对该方法的调用者
需要修好这个问题的人
举例 另一种返回方式
程序bug，硬件系统故障，配置错误，丢失的文件，服务器没有运行
补充：软件开发 , Java ,
