|
|
|
|
移动端

36 报告所有的异常

《高效程序员的45个习惯:敏捷开发修炼之道》本书总结并生动地阐述了成为高效的开发人员所需具备的 45个习惯、思想观念和方法,涵盖了软件开发进程、编程和调试工作、开发者态度、项目和团队管理以及持续学习等几个方面。本节为大家介绍报告所有的异常。

作者:钱安川/郑柯 译来源:人民邮电出版社|2010-03-04 08:57

开发者盛宴来袭!7月28日51CTO首届开发者大赛决赛带来技术创新分享

36 报告所有的异常

"不要让程序的调用者看到那些奇怪的异常。处理它们是你的责任。把你调用的一切都包起来,然后发送自己定义的异常--或者干脆自己解决掉。"

从事任何编程工作,都要考虑事物正常状况下是如何运作的。不过更应该想一想,当出现问题--也就是事情没有按计划进行时,会发生什么。

在调用别人的代码时,它也许会抛异常,这时我们可以试着对其处理,并从失败中恢复。当然,要是在用户没有意识到的情况下,可以恢复并继续正常处理流程,这就最好不过了。要是不能恢复,应该让调用代码的用户知道,到底是哪里出现了问题。

不过也不尽然。Venkat曾经在使用一个非常流行的开源程序库(这里就不提它的名字了)时倍受打击。他调用的一个方法本来应该创建一个对象,可是得到的却是null引用。涉及的代码量非常少,而且没有其他代码发生联系,也很简单。所以从他自己写的这块代码的角度来看,不太可能出问题,他摸不到一点头绪。

幸好这个库是开源的,所以他下载了源代码,然后带着问题检查了相关的方法。这个方法调用了另外的方法,那个方法认为他的系统中缺少了某些必要的组件。这个底层方法抛出了带有相关信息的异常。但是,上层方法却偷偷地用没有异常处理代码的空catch代码块,把异常给忽略掉了,然后就抛出一个null。Venkat所写的代码根本不知道到底发生了什么,只有通过阅读程序库的代码,他才能明白这个问题,并最后安装了缺失的组件。

像Java中那样的检查异常会强迫你捕捉异常,或是把异常传播出去。可是有些开发人员会采取临时的做法:捕捉到异常后,为了不看到编译器的提示,就把异常忽略掉。这样做很危险--临时的补救方式很容易被遗忘,并且会进入到生产系统的代码中。必须要处理所有的异常,倘若可以,从失败中恢复再好不过。如果不能处理,就要把异常传播到方法的调用者,这样调用者就可以尝试对其进行处理了(或者以优雅的方式将问题的信息告诉给用户,见习惯37)。

听起来很明白,是吧?其实不像想象得那么容易。不久前有一条新闻,提到一套大型航空订票系统中发生了严重的问题。系统崩溃,飞机停飞,上千名旅客滞留机场,整个航空运输系统数天之内都乱作一团。原因是什么?在一台应用服务器上发生了一个未检查异常。

也许你很享受CNN新闻上提到你名字的感觉,但是你不太可能希望发生这样的情形。

处理或是向上传播所有的异常。不要将它们压制不管,就算是临时这样做也不行。在写代码时要估计到会发生的问题。

切身感受

当出现问题时,心里知道能够得到抛出的异常。而且没有空的异常处理方法。

平衡的艺术

决定由谁来负责处理异常是设计工作的一部分。

不是所有的问题都应该抛出异常。

报告的异常应该在代码的上下文中有实际意义。在前述的例子中,抛出一个NullPointerException看起来也许不错,不过这就像抛出一个null对象一样,起不到任何帮助作用。

如果代码中会记录运行时调试日志,当捕获或是抛出异常时,都要记录日志信息;这样做对以后的跟踪工作很有帮助。

检查异常处理起来很麻烦。没人愿意调用抛出31种不同检查异常的方法。这是设计上的问题:要把它解决掉,而不是随便打个补丁就算了。

要传播不能处理的异常。

【责任编辑:云霞 TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

SQL Server 2005数据挖掘与商业智能完全解决方案

本书以BI解决方案的体系结构为中心,以SQL Server 2005为载体,将着眼点放在数据挖掘和商业智能上,详细讲解了数据报表、数据分析和数据挖...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊