ITPub博客

首页 > Linux操作系统 > Linux操作系统 > [转载]java的异常处理机制

[转载]java的异常处理机制

原创 Linux操作系统 作者:dinner1007 时间:2019-02-28 11:03:04 0 删除 编辑
java的异常处理机制
关于 Java 中引入的 Checked Exceptions,目前存在着很多反对意见。正方的观点是引入 Checked Exceptions,可以增加程度的鲁棒性。反方的观点是 Checked Exceptions 很少被开发人员正确使用过,并且降低了程序开发的生产率和代码的执行效率。
正方代表 James Gosling
http://www.artima.com/intv/solid.html
反方代表 Anders Hejlsberg
http://www.artima.com/intv/csdes.html
中文版:http://www.csdn.net/develop/article/22/22612.shtm


我的一些观点:

第一部分 选择checked or unchecked

这里需要对异常的理解。什么算异常?java的异常处理机制是用来干什么的?异常和错误有什么区别?

异常机制就是java的错误处理机制!java中的异常意味着2点:第一,让错误处理代码更有条理。这使得
正常代码和错误处理代码分离。第二,引入了context的概念,认为有些错误是可以被处理的。问题就出在这儿了。

java的checked异常指的就是在当前context不能被处理的错误!

这句话其实是对上面2点的总结。首先checked异常是一种错误,其次这种错误可以被处理(或修复)。

checked异常就是可以被处理(修复)的错误,unchecked异常其实就是无法处理(修复)的错误。

说到这儿,应该清楚了。别的语言没有checked异常,就是说它们认为错误都无法被修复,至少在语言级
不提供错误修复的支持。java的catch clause干的就是错误修复的事。

我的理解是,用好java的异常,其实就是搞清楚什么时候该用checked异常。应该把unchecked异常当作
缺省行为。unchecked异常的意思是:当我做这件事时,不可思议的情况发生了,我没办法正常工作下去!
然后抛出一个unchecked异常,程序挂起。而checked异常的意思是:当我做这件事时,有意外情况发生,
可以肯定的是,活是没法干了,但是要不要挂起程序,我这个函数没法做主,我只能汇报上级!

其实,从上面的分析可以看出,java引入checked异常只是让程序员多了一个选择,它并不强迫你使用checked异常。

如果你对什么时候应该使用checked异常感到迷惑,那么最简单的办法就是,不要使用checked异常!这里包括2个
方面:

第一,你自己不必创建新的异常类,也不必在你的代码中抛出checked异常,错误发生后只管抛出unchecked异常;
第二,对已有API的checked异常统统catch后转为unchecked异常!

使用unchecked异常是最省事的办法。用这种方法也可以享受“正常代码和错误处理代码分离”的好处。因为我们在调用方法时,
不用根据其返回值判断是否有错误出现,只管调用,只管做正事就ok了。如果出现错误,程序自然会知道并挂起。这样的效果是怎样
的呢?

第一,我们的业务代码很清晰,基本都是在处理业务问题,而没有一大堆判断是否有错的冗余代码。(想想看,如果没有
throw异常的机制,你只能通过函数的返回值来判断错误,那么你在每个调用函数的地方都会有判断代码!)
第二,我们的代码假设一切正常,如果确实如此,那么它工作良好。但是一旦出现任何错误,程序就会挂起停止运行。当然,你可以查看
日志找到错误信息。

那么使用checked异常又是怎样的呢?

第一,你需要考虑更多的问题。首先在设计上就会更加复杂,其次就是代码更加冗长。设计上复杂
体现在以下方面:

1 对异常(错误)的抽象和理解。你得知道什么情况才能算checked异常,使得上级确实能够处理(修复)这种异常,并且让整个程序
从这种设计中确实得到好处。

2 对整个自定义checked异常继承体系的设计。正如那篇文章所说,总不能在一个方法后面抛出20个异常吧!设计自定义checked异常,
就要考虑方法签名问题,在合适的时候抛出合适的异常(不能一味的抛出最具体的异常,也不能一味抛出最抽象的异常)

第二,业务代码相比较使用unchecked的情况而言,不够直接了当了。引入了throws签名和catch clause,代码里有很多catch,方法
签名也和异常绑定了。

第三,有了更强的错误处理能力。如果发生了checked异常,我们有能力处理(修复)它。表现在不是任何错误都会导致程序挂起,出现了
checked异常,程序可能照样运行。整个程序更加健壮,而代价就是前面2条。


第二部分 使用checked异常的最佳实践

现在假设有些错误我们确定为checked异常,那么我们针对这些checked异常要怎样编码才合理呢?

1 不要用checked异常做流程控制。无论如何,checked异常也是一种错误。只是我们可以处理(修复)它而已。这种错误和普通业务
流程还是有区别的,而且从效率上来说,用异常控制业务流程是不划算的。其实这个问题有时候很难界定,因为checked异常“可以修复”,
那么就是说修复后程序照常运行,这样一来真的容易跟普通业务流程混淆不清。比如注册用户时用户名已经存在的问题。这个时候我们要考虑,
为什么要用checked异常?这和使用业务流程相比,给我带来了什么好处?(注意checked异常可以修复,这是和unchecked异常本质的区别)
照我的理解,checked异常应该是介于正常业务流程和unchecked异常(严重错误)之间的一种比较严重的错误。出现了这种错误,程序无法
完成正常的功能是肯定的了,但我们可以通过其他方式弥补(甚至修复),总之不会让程序挂起就是。其实这一点也是设计checked异常时要考虑
的问题,也是代价之一吧。

2 对checked异常的封装。这里面包括2个问题:

第一,如果要创建新的checked异常,尽量包含多一点信息,如果只是一条message,那么用Exception好了。当然,用Exception会
失去异常的型别信息,让客户端无法判断具体型别,从而无法针对特定异常进行处理。

第二,不要让你要抛出的checked exception升级到较高的层次。例如,不要让SQLException延伸到业务层。这样可以避免方法
签名后有太多的throws。在业务层将持久层的所有异常统统归为业务层自定义的一种异常。

3 客户端调用含有throws的方法要注意:

第一,不要忽略异常。既然是checked异常,catch clause里理应做些有用的事情——修复它!catch里为空白或者仅仅打印出错信息都是
不妥的!为空白就是假装不知道甚至瞒天过海,但是,出来混迟早要还的,迟早会报unchecked异常并程序挂起!非典就是个例子。
打印出错信息也好不到哪里去,和空白相比除了多几行信息没啥区别。如果checked异常都被这么用,那真的不如当初都改成unchecked好了,
大家都省事!

第二,不要捕获顶层的Exception。你这么干,就是在犯罪!因为unchecked异常也是一种Exception!你把所有异常都捕获了——不是我
不相信你的能力,你根本就不知道该如何处理!这样做的直接的后果就是,你的程序一般来说是不会挂起了,但是出现错误的时候功能废了,
表面上却看不出什么!当然,深究起来,这也不是什么罪大恶极,如果你在catch里打印了信息,这和上面那条的情况是差不多的。而这2条
的共同点就是,没有正确使用checked异常!费了那么大劲设计的checked异常就是给你们上级(客户端)用的,结果你们不会用!真的
不如用unchecked干脆利落了!

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/374079/viewspace-130866/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-08-23

  • 博文量
    1714
  • 访问量
    1293972