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