扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
来源:CSDN 2008年02月28日
关键字:java Three Rules Exception
Translator comments
:readPreferences()函数里。这样在界面上可以以对话框的形式提示的用户相关信息或者使用其它的处理方式。这就是我们待会儿将会讨论的“晚捕获”原则。
Translator comments:
所谓具体化为:
定义具体的代表某个特定错误的异常类。
方法声明特定的异常类。
方法捕获具体类。
目地:具体问题具体处理。
早抛出
通过Stack trace向我们展示的引起异常的方法调用顺序、类名、方法名、原代码文件名以及每个方法调用的行号,这样可以帮助我们精确地定位异常发生的地方。考虑下面的Stack trace信息:
java.lang.NullPointerException
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:103)
at jcheckbook.JCheckbook.readPreferences(JCheckbook.java:225)
at jcheckbook.JCheckbook.startup(JCheckbook.java:116)
at jcheckbook.JCheckbook.<init>(JCheckbook.java:27)
at jcheckbook.JCheckbook.main(JCheckbook.java:318)
这表明类FileInputStream的open方法抛出一个NullPointerException异常,但注意到 FileInputStream.open()是JAVA标准类库的一部分。这样引起异常的原因很可能在我们自己代码里面,而不JAVA API,所以问题一定出在这之前的某个方法内,幸运的是它被显示了出来。
很不幸,异常NullPointerException恰好是JAVA中能提供有效信息最少的异常类中的一个。它并不能告诉我们真正想知道的。同时我们也需要向后追踪去找到错误发生地。
通过向后追踪Stack trace和检查我们的代码,我们发现错误是由于调用方法readPreferences()时传入的文件名为null,因为方法知道一个空文件名将使方法不能再执行下去,所以它立即检查这个条件:
public void readPreferences(String filename)
throws IllegalArgumentException
{
if (filename == null)
{
throw new IllegalArgumentException
("filename is null");
} //if
//...perform other operations...
InputStream in = new FileInputStream(filename);
//...read the preferences file...
}
因为比较早的抛出了异常,所以异常就变得更加具体和准确了。Stack trace也很准确地反映出发生了什么异常,为什么及在什么地方。这样使得Stack trace更加准确的反映了本来程序所发生的一切:
java.lang.IllegalArgumentException: filename is null
at jcheckbook.JCheckbook.readPreferences(JCheckbook.java:207)
at jcheckbook.JCheckbook.startup(JCheckbook.java:116)
at jcheckbook.JCheckbook.<init>(JCheckbook.java:27)
at jcheckbook.JCheckbook.main(JCheckbook.java:318)
另外,异常信息(“filename is null”)指出了是什么为空,从而使得异常附带更多有用的信息。而这些是我们无法从异常NullPointerException中获得的。
一旦出错误就立即抛出异常,这样可以避免再去构造或找开那些不再需要的对象或资源。比如说文件或网络连接。与打开这些资源相关的清理工作也可以避免了。
晚捕获
许多JAVA开发人员,无论新手或老手都普遍地犯一个错误就是在程序有能力处理一个异常之前就将它捕获了。JAVA编译器坚持让Checked Exception不是要被捕获就一定要在函数头中声明的作法也客观上促使了程序员采用上面这一错误作法。对程序员来说,一个很自然的趋势就是让代码包括在try程序块中并捕捉异常以阻止编译器报错。
问题是当捕获到异常之后你该如何处理它了?最坏的事情就是不做任何处理。一个空的catch块使异常无端地消失了从而使得关于异常的What、Where、Why信息永远丢失了。将异常的信息Log下来使情况稍好点,毕竟那样还有关于异常信息的记录。但是我们不可能期望用户想看甚至看懂Log文件和Stack trace信息。在函数readPreferences()内显示异常信息对话框是不合适的。因为Jcheckbook目前运行为桌面程序,我们也计划将其改写为基于HTML或者C/S的版本。
功能从Server上获取,而错误需要在浏览器或客户端中显示。我们应该带着为未来着想的想法去设计readPreferences()方法。恰当的将用户交互代码从程序逻辑中分开可以增加代码的可重用性。
readPreferences()方法立即捕获并处理了在调用FileInputStream构造函数所产生的FileNotFoundException异常,代码如下:
readPreferences ()将会发生什么?当然,异常FileNotFoundException将会被Log,如果我们恰好去检查Log文件,我们将会意识到异常的发生。但如果程序继续去读那个文件当中的数据,那会发生什么了?因为文件不存在,in是null,所以一个NullPointerException将会被抛出。
当是调试程序时,直觉会使我们在日志文件中去检查最近的信息,你会非常恐惧的看到一个NullPointerException异常,因为它太一般了,不能提供你有价值的对判断异常发生原因有帮助的任何信息,Stack trace也是,这不仅使你无法了解错误是什么(真的错误是FileNotFoundException而不是 NullPointerException),而且也无法了解错误发生的正确地点。
除了catch异常外,readPreferences()方法还能对异常做何处理了?可能跟我们的直觉相反,仅仅将它上抛就可以了,不要立即catch异常。将处理的责任上抛给readPreferences()的调用者,让它去决定采用合适的方法去处理文件引用丢失的问题,它可以提示用户要求另一个文件、使用默认的值或者如果没有其它的办法,提示用户有问题发生并退出程序的运行也是可以。
这种将异常处理的任务上抛给它的调动链上的方法就是用throws关键字在方法头声明这些需要上抛的异常。当声明这些异常时,请尽可能使用能代表具体问题的异常类。这样可以使调动你方法的程序可以预料到到底会发生哪些异常并根椐具体情况处理它们。将前面代码修改如下:
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。