至顶网›软件频道 ›Three Rules for Effective Exception Handling(中文)

Three Rules for Effective Exception Handling(中文)

扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条

有经验的开发人员都知道调试程序最难的部分不是修改Bug,而是找出Bug的藏身之处。通过使用上面所讲的三个原则，你就可以使异常帮助你追踪和清除Bugs并且使得你程序更加健壮和友好。

作者：Leon_He 来源：CSDN 2008年2月28日

晚捕获

许多JAVA开发人员，无论新手或老手都普遍地犯一个错误就是在程序有能力处理一个异常之前就将它捕获了。JAVA编译器坚持让Checked Exception不是要被捕获就一定要在函数头中声明的作法也客观上促使了程序员采用上面这一错误作法。对程序员来说，一个很自然的趋势就是让代码包括在try程序块中并捕捉异常以阻止编译器报错。

问题是当捕获到异常之后你该如何处理它了？最坏的事情就是不做任何处理。一个空的catch块使异常无端地消失了从而使得关于异常的What、Where、Why信息永远丢失了。将异常的信息Log下来使情况稍好点，毕竟那样还有关于异常信息的记录。但是我们不可能期望用户想看甚至看懂Log文件和Stack trace信息。在函数readPreferences()内显示异常信息对话框是不合适的。因为Jcheckbook目前运行为桌面程序，我们也计划将其改写为基于HTML或者C/S的版本。

功能从Server上获取，而错误需要在浏览器或客户端中显示。我们应该带着为未来着想的想法去设计readPreferences()方法。恰当的将用户交互代码从程序逻辑中分开可以增加代码的可重用性。

在有能力处理一个异常之前去捕获它，常常会进一步地引起其它的错误和异常。比如，像

readPreferences()方法立即捕获并处理了在调用FileInputStream构造函数所产生的FileNotFoundException异常，代码如下：

public void readPreferences(String filename)

{

//...

InputStream in = null;

// DO NOT DO THIS!!!

try

{

in = new FileInputStream(filename);

}

catch (FileNotFoundException e)

{

logger.log(e);

}

in.read(...);

//...

}

这段代码在对恢复错误无能为力的情况下捕捉了异常FileNotFoundException。如果文件没有找到，剩下的方法体肯定执行不起来。用一个不存在的文件名去调用方法

readPreferences ()将会发生什么？当然，异常FileNotFoundException将会被Log，如果我们恰好去检查Log文件，我们将会意识到异常的发生。但如果程序继续去读那个文件当中的数据，那会发生什么了？因为文件不存在，in是null,所以一个NullPointerException将会被抛出。

当是调试程序时，直觉会使我们在日志文件中去检查最近的信息，你会非常恐惧的看到一个NullPointerException异常，因为它太一般了，不能提供你有价值的对判断异常发生原因有帮助的任何信息,Stack trace也是，这不仅使你无法了解错误是什么(真的错误是FileNotFoundException而不是 NullPointerException)，而且也无法了解错误发生的正确地点。

除了catch异常外，readPreferences()方法还能对异常做何处理了？可能跟我们的直觉相反，仅仅将它上抛就可以了，不要立即catch异常。将处理的责任上抛给readPreferences()的调用者,让它去决定采用合适的方法去处理文件引用丢失的问题，它可以提示用户要求另一个文件、使用默认的值或者如果没有其它的办法，提示用户有问题发生并退出程序的运行也是可以。

这种将异常处理的任务上抛给它的调动链上的方法就是用throws关键字在方法头声明这些需要上抛的异常。当声明这些异常时，请尽可能使用能代表具体问题的异常类。这样可以使调动你方法的程序可以预料到到底会发生哪些异常并根椐具体情况处理它们。将前面代码修改如下：

public void readPreferences(String filename)

throws IllegalArgumentException,

FileNotFoundException, IOException

{

if (filename == null)

{

throw new IllegalArgumentException

("filename is null");

} //if

//...

InputStream in = new FileInputStream(filename);

//...

}

从技术上说，我们唯一需要声明的就是IOException，但是通过声明此方法可能会抛出FileNotFoundException可以帮助调用者更好的处理异常。而异常IllegalArgumentException是不需要声明的，因为它是一个Unchecked Exception（为RuntimeException的子类）仍然将其包括在其中是因为这样使代码更清晰[特别对调用者而言]。

当然，最终你的程序仍需捕获异常，要么程序就会意外地中止。但这个原则的意义就在于，它可以让你在合适地方捕获异常并能够提供合适的异常处理方法，不会再引起其它的异常，从而让程序能继续运行。或者提供用户一些具体有用的信息，包括如何从错误中恢复过来一些指示。当一个方法对异常不能做这两者之一时，简单地将异常上抛，这样它就会在合适的地方被捕获并处理。

总结

有经验的开发人员都知道调试程序最难的部分不是修改Bug,而是找出Bug的藏身之处。通过使用上面所讲的三个原则，你就可以使异常帮助你追踪和清除Bugs并且使得你的程序更加健壮和友好。

Three Rules for Effective Exception Handling(中文)

Three Rules for Effective Exception Handling(中文)

VIP专区

VIP用户

普通用户

邮件订阅

如果您非常迫切的想了解IT领域最新产品与技术信息，那么订阅至顶网技术邮件将是您的最佳途径之一。

重磅专题

往期文章

Three Rules for Effective Exception Handling(中文)

业界热点: