《高效的java异常处理.doc》由会员分享，可在线阅读，更多相关《高效的java异常处理.doc（9页珍藏版）》请在金锄头文库上搜索。
1、1基本信息摘要：本文倡导一种对异常条件本质的思考方式，并描述一些有助于设计的模式。最后，本文还将在AOP模型中，作为相互渗透的问题，来讨论异常的处理。当你能正确使用异常时，它们会有极大的好处。本文将帮助你做到这一点。原作者：Barry Ruzek 译者： 易晓斓，原文：http:/ 图1：Java异常的等级通常，Java编译器强迫抛出基于java.lang.Throwable的异常的方法要在它声明中的“throws”部分加上那个异常。而且，编译器还会证实客户端的方法或者捕获已声明的异常，或者特别声明自己也抛出同样的异常。这些简单的规则对世界范围的Java程序员都有深远的影响。编译器放松了对Th
2、rowable继承树中两个分支的异常检查。java.long.Error和java.lang.RuntimeException 的子类免于编译时的检查。在这两类中，软件工程师通常对运行中异常更感兴趣。“不检查”的异常指的是这一组，以便和所有其它“检查”的异常区别开。我可以想象那些接受“检查”的异常的人，也会很看重Java的数据类型。毕竟，编译器对数据类型施加的限制鼓励严格的编码和精确的思维。编译时的类型检查对减少运行时的严重问题有帮助。编译时的异常检查也能起到类似的作用，它会提醒开发人员某个方法可能会有预想不到的结果需要处理好。早期的建议是尽可能的使用“检察的异常”，以此来最大限度的利用编译器
3、提供的帮助来写出无错误的软件。Java类库API的设计者们都认同这一点，他们广泛地使用“检察的异常”来模拟类库方法中几乎所有的紧急应变措施。在J2SE5.1 API规格中，“检察的异常”类型已2比1的比率超过了“未检查的异常”类型。对程序员而言，看上去在Java类库中大多数的常用方法对每一个可能的失败都声明了“检察的异常”。例如，java.io包对IOException这个“检察的异常”就有着很大的依赖。至少有63个Java类库包，或直接，或通过十几个下面的子类，抛出这个异常。I/O的失败极其稀有，但是却很严重。而且，一旦发生，从你所写的代码里基本上是无法补救的。Java程序员意识到他们不得不
4、提供IOException 或类似的不可补救的事件，而一个简单的Java类库方法的调用就可能让这些事件发生。捕获这些异常给本来简单的代码带来了一定的晦涩，因为即使在捕获的代码块里也基本上帮不上忙。但是不加以捕获又可能更糟糕，因为编译器要求你的方法必须要抛出那些异常。这样你的实施细则就不得不暴露在外了，而通常好的面向对象的设计都是要隐藏细节的。这样一个不可能赢的局面导致了我们今天所警告的绝大多数臭名卓著的异常处理的颠覆性格局。同时也衍生了很多正确或错误的补救之道。一些Java界的知名人物开始质疑Java的“检察的异常”的模型是否是一个失败的试验。有一些东西肯定是失败的，但是这和在Java语言里加
5、入对异常的检查是毫无关联的。失败是由于在Java API的设计者们的思维里，大多数失败的情形是雷同的，所以可以通过同一种异常传达出去。4故障和应变让我们来考虑在一个假想的银行应用中的CheckingAccount类。一个CheckingAcccount属于一个用户，记载着用户的存款余额，也能接受存款，接受止兑的通知，和处理汇入的支票。一个CheckingAcccount对象必须协调同步线程的访问，因为任何一个线程都可能改变它的状态。CheckingAcccount类里processCheck的方法会接受一个Check对象为参数，通常从帐户余额里减去支票的金额。但是一个管理支票清算的用户端程序调
6、用processCheck方法时，必须有两种可能的应变措施。一，CheckingAccount对象里可能对该支票已有一个止付的命令；二，帐户的余额可能不足已满足支票的金额。所以，processCheck的方法对来自客户端的调用可以有3种方式回应。正常的是处理好支票，并把方法签名里声明的结果返回给调用方。两种应变的回应则是需要与支票清算端沟通的在银行领域实实在在存在的情况。processCheck方法所有3种返回结果都是按照典型的银行支票帐户的行为而精心设计的。在Java里，一个自然的方法来表示上述紧急的应变是定义两种异常，比如StopPaymentException（止付异常）和 Insuff
7、icientFundsException（余额不足异常）。一个客户端如果忽略这些异常是不对的，因为这些异常在正常操作的情况下一定会被抛出。他们如同方法的签名一样反映了方法的全面行为。客户端可以很容易的处理好这两种异常。如果对支票的兑付被停止了，客户端把该支票交付特别处理。如果是因为资金不足，用户端可以从用户的储蓄帐户里转移一些资金到支票帐户里，然后再试一次。在使用CheckingAccount的API时，这些应变都是可以预计的和自然的结果。他们并不是意味着软件或运行环境的失败。这些异常和由于CheckingAccount类中一些内部实施细则引起的真正失败是不同的。设想CheckingAccou
8、nt对象在数据库里保持着一个恒定的状态，并使用JDBC API来对之访问。在那个API里，几乎所有的数据库访问方法都有可能因为和CheckingAccount实施无关的原因而失败。比如，有人可能忘了把数据库服务器运行起来，一个未有连上的网络数据线，访问数据库的密码改变了，等等。JDBC依靠一种“检查的异常”，SQLException，来汇报任何可能的错误。可能出错的绝大多数原由都是数据库的配置，连接，或其所在的硬件设施。对processCheck方法而言，它对上述错误是无计可施的。这不应该，因为processCheck至少了解它自己的实施细则。在调用栈里上游的方法能处理这些问题的可能就更小。C
9、heckingAccount这个例子说明了一个方法不能成功返回它想要的结果的两个基本原因。这里是两个描述性的术语：应变 与实际预料相符，一个方法给出另外一种回应，而这种回应可以表达成该方法所要达到的目的之一。这个方法的调用者预料到这个情况的出现，并有相对的应付之道。故障 在未经计划的情况下，一个方法不能达到它的初衷，这是一个不诉诸该方法的实施细则就很难搞清的情况。 应用这些术语，对processCheck方法而言，一个止付的命令和一个超额的提取是两种可能的应变。而SQLException反映了可能的故障。processCheck方法的调用者应该能够提供应变，但却不一定能有效的处理好可能发生的故
10、障。Java异常的匹配 在建立应用架构中Java异常的规则时，以应变和故障的方式仔细考虑好“什么可能会出错”是有长远意义的。应变情况恰如其分地匹配给了Java检查的异常。因为它们是方法的语义算法合同中不可缺少的一部分，在这里借助于编译器的帮助来确保它们得到解决是很有道理的。如果你发现编译器坚持应变的异常必须要处理或者在不方便的时候必须要声明会给你带来些麻烦，你在设计上几乎肯定要做些重构了。这其实是件好事。出现故障的情况对开发人员而言是蛮有意思的，但对软件逻辑而言却并非如此。那些软件”消化问题“的专家们需要关于故障的信息以便来解决问题。因此，未检查的异常是表示故障的很好方式。他们让故障的通知原封
11、不动地从调用栈上所有的方法滤过，到达一个专门来捕获它们的地方，并得到它们自身包含的有利于诊断的信息，对整个事件提供一个有节制的优雅的结论。产生故障的方法不需要来声明（异常），上游的调用方法不需要捕获它们，方法的实施细则被正确的隐藏起来 以最低的代码复杂度。新一些的Java API，比如像Spring架构和Java Data Ojects类库对检查的异常几乎没有依赖。Hibernate ORM架构在3.0版本里重新定义了一些关键功能来去除对检查的异常的使用。这就意味着在这些架构举报的绝大部分异常都是不可恢复的，归咎于错误的方法调用代码，或是类似于数据库服务器之类的底层部件的失败。特别的，强迫一个
12、调用方来捕获或声明这些异常几乎没有任何好处。设计里的故障处理在你的计划里，承认你需要去做就迈好了有效处理好故障的第一步。对那些坚信自己能写出无懈可击的软件的工程师们来说，承认这一点是不容易的。这里是一些有帮助的思考方式。首先，如果错误俯拾即是，应用的开发时间将很长，当然前提是程序员自己的bug自己修理。第二，在Java类库中，过度使用检查的异常来处理故障情形将迫使你的代码要应对好故障，即使你的调用次序完全正确。如果没有一个故障处理的架构，凑合的异常处理将导致应用中的信息丢失。一个成功的故障处理架构一定要达到下面的目标：减少代码的复杂性 捕获和保存诊断性信息 对合适的人提醒注意 优雅地退出行动 故障是应用的真实意图的干扰。因此，用来处理它们的代码应尽量的少，理想上，把它们和应用的语义算法部分隔离开。故障的处理必须满足那些负责改正它们的人的需要。开发人员需要知道故障发生了，并得到能帮助他们搞清为何发生的信息。即使一个故障，在定义上而言，是不可补救的，好的故障处理会试着优雅地结束引起故障的活动。对故障情况使用未检查的异常在做框架上的决定时，用未检查的异常来代表故障情况是有很多原因的。Java的运行环境对代码的错误会抛出“运行时异常”的子类，比如， ArithmeticExc
