10.6 异常处理规则

前面介绍了使用异常处理的优势、便捷之处,本节将进一步从程序性能优化、结构优化的角度给出异常处理的一般规则。成功的异常处理应该实现如下4个目标

使程序代码混乱最小化。
捕获并保留诊断信息。
通知合适的人员。
采用合适的方式结束异常活动。

下面介绍达到这种效果的基本准则。

10.6.1 不要过度使用异常

不可否认,Java的异常机制确实方便,但滥用异常机制也会带来一些负面影响。过度使用异常主要有两个方面。

把异常和普通错误混淆在一起,不再编写任何错误处理代码,而是以简单地抛岀异常来代替所有的错误处理。
使用异常处理来代替流程控制

熟悉了异常使用方法后,程序员可能不再愿意编写烦琐的错误处理代码,而是简单地抛出异常。实际上这样做是不对的,对于完全已知的错误,应该编写处理这种错误的代码,增加程序的健壮性;对于普通的错误,应该编写处理这种错误的代码,增加程序的健壮性。只有对外部的、不能确定和预知的运行时错误才使用异常。

必须指出:异常处理机制的初衷是将不可预期异常的处理代码和正常的业务逻辑处理代码分离,因此绝不要使用异常处理来代替正常的业务逻辑判断。
另外,异常机制的效率比正常的流程控制效率差,所以不要使用异常处理来代替正常的程序流程控制。

总结

异常只应该用于处理非正常的情况,不要使用异常处理来代替正常的流程控制。
对于一些完全可预知,而且处理方式清楚的错误,程序应该提供相应的错误处理代码,而不是将其笼统地称为异常。

10.6.2 不要使用过于庞大的try块

很多初学异常机制的读者喜欢在try块里放置大量的代码,在一个try块里放置大量的代码看上去很简单”,但这种”简单”只是一种假象,只是在编写程序时看上去比较简单。但因为try块里的代码过于庞大,业务过于复杂,就会造成try块中出现异常的可能性大大增加,从而导致分析异常原因的难度也大大增加。
而且当try块过于庞大时,就难免在try块后紧跟大量的catch块才可以针对不同的异常提供不同的处理逻辑。同一个try块后紧跟大量的catch块则需要分析它们之间的逻辑关系,反而增加了编程复杂度。
正确的做法是,把大块的try块分割成多个可能出现异常的程序段落,并把它们放在单独的try块中,从而分别捕获并处理异常。

10.6.3 避免使用Catch All语句

所谓Catch All语句指的是一种异常捕获模块,它可以处理程序发生的所有可能异常。例如,如下代码片段:

try
{
    //可能引发 Checked异常的代码
}
catch (Throwable t)
{
    //进行异常处理
    t.printstackTrace();
}

不可否认,每个程序员都曾经用过这种异常处理方式;但在编写关键程序时就应避免使用这种异常处理方式。这种catch All异常处理方式有如下两点不足之处。

所有的异常都采用相同的处理方式,这将导致无法对不同的异常分情况处理,如果要分情况处理,则需要在catch块中使用分支语句进行控制,这是得不偿失的做法。
这种捕获方式可能将程序中的错误、 Runtime异常等可能导致程序终止的情况全部捕获到,从而”压制”了异常。如果出现了一些”关键”异常,那么此异常也会被”静悄悄”地忽略。

实际上, Catch All语句不过是一种通过避免错误处理而加快编程进度的机制,应尽量避免在实际应用中使用这种语句。

10.6.4 不要忽略捕获到的异常

不要忽略异常!既然已捕获到异常,那catch块理应做些有用的事情——处理并修复这个错误。catch块整个为空,或者仅仅打印出错信息都是不妥的!

catch块为空就是假装不知道甚至瞒天过海,这是最可怕的事情——程序出了错误,所有的人都看不到任何异常,但整个应用可能已经彻底坏了。
仅在catch块里打印错误跟踪栈信息稍微好一点,但仅仅比空白多了几行异常信息。

通常建议对异常采取适当措施,比如:

处理异常。对异常进行合适的修复,然后绕过异常发生的地方继续执行;或者用别的数据进行计算,以代替期望的方法返回值;或者提示用户重新操作……总之,对于Checked异常,程序应该尽量修复。
重新抛出新异常。把当前运行环境下能做的事情尽量做完,然后进行异常转译,把异常包装成当前层的异常,重新抛出给上层调用者。
在合适的层处理异常。如果当前层不清楚如何处理异常,就不要在当前层使用catch语句来捕获该异常,直接使用throws声明抛出该异常,让上层调用者来负责处理该异常。

原文链接: 10.6 异常处理规则