高效的Java异常处理 - 编程入门网

设计里的故障处理

在你的计划里，承认你需要去做就迈好了有效处理好故障的第一步。对那些坚信自己能写出无懈可击的软件的工程师们来说，承认这一点是不容易的。这里是一些有帮助的思考方式。首先，如果错误俯拾即是，应用的开发时间将很长，当然前提是程序员自己的bug自己修理。第二，在Java类库中，过度使用检查的异常来处理故障情形将迫使你的代码要应对好故障，即使你的调用次序完全正确。如果没有一个故障处理的架构，凑合的异常处理将导致应用中的信息丢失。

一个成功的故障处理架构一定要达到下面的目标：

减少代码的复杂性

捕获和保存诊断性信息

对合适的人提醒注意

高效的Java异常处理(4)

优雅地退出行动

故障是应用的真实意图的干扰。因此，用来处理它们的代码应尽量的少，理想上，把它们和应用的语义算法部分隔离开。故障的处理必须满足那些负责改正它们的人的需要。开发人员需要知道故障发生了，并得到能帮助他们搞清为何发生的信息。即使一个故障，在定义上而言，是不可补救的，好的故障处理会试着优雅地结束引起故障的活动。

对故障情况使用未检查的异常

在做框架上的决定时，用未检查的异常来代表故障情况是有很多原因的。Java的运行环境对代码的错误会抛出“运行时异常”的子类，比如，ArithmeticException或ClassCastException。这为你的框架设了一个先例。未检查的异常让上游的调用方法不需要为和它们目的不相关的情况而添加代码，从而减少了混乱。

你的故障处理策略应该认识到Java类库的方法和其他API可能会使用检查的异常来代表对你的应用而言只可能是故障的情况。在这种情形下，采用设计约定来捕获API异常，将其以故障来看待，抛出一个未检查的异常来指示故障的情况和捕获诊断的信息。

在这种情况下抛出的特定异常类型应该由你的框架来定义。不要忘记一个故障异常的主要目的是传递记录下来的诊断信息，以便让人们来想出出错的原因。使用多个故障异常类型可能有些过，因为你的架构对它们都一视同仁。多数情况下，一条好的，描述性强的信息将单一的故障类型嵌入就够用了。使用Java基本的RuntimeException来代表故障情况是很容易的。截止到Java1.4，RuntimeException，和其他的抛出类型一样，都支持异常的嵌套，这样你就可以捕获和报出导向故障的检查的异常。

你也许会为了故障报告的目的而定义你自己的未检查的异常。这样做可能是必要的，如果你使用Java1.3或更早的版本，它们都不支持异常的嵌套。实施一个类似的嵌套功能来捕获和转换你应用中构成故障的检查的异常是很简单的。你的应用在报错时可能需要一个特殊的行为。这可能是你在架构中创建RuntimeException子类的另一个原因。

建立一个故障的屏障

对你的故障处理架构而言，决定抛出什么样的异常，何时抛出是重要的决定。同样重要的是，何时来捕获一个故障异常，之后再怎么办。这里的目的是让你应用中的功能性部分不需要处理故障。把问题分开来处理通常都是一件好事情，有一个中央故障处理机制长远来看是很有裨益的。

在故障屏障的模式里，任何应用组件都可以抛出故障异常，但是只有作为“故障屏障”的组件才捕获异常。采用此种模式去除了大多数程序员为了在本地处理故障而插入的复杂的代码。故障屏障逻辑上位于调用栈的上层，这样在一个默认的行动被激发前，一个异常向上举报的行为就被阻止了。根据不同的应用类型，默认的行动所指也不同。对一个独立的Java应用而言，这个行动指活着的线程被停止。对一个位于应用服务器上的Web应用而言，这个行动指应用服务器向浏览器送出不友好的（甚至令人尴尬的）回应。

一个故障屏障组件的第一要务就是记录下故障异常中包

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!