我想anders的另一个观点在于:exception spec复杂化了接口签名,复杂化了语言。很明显的一点,引入了generics的话,exception spec就让情况复杂很多。
总而言之,在有得有失,利弊难说的时候,保持简单也许是一个从长远角度考虑的正确决定。加一个东西永远比去掉一个东西容易。(当然,眼前确实可能会让软件不那么健壮了)
-----------------------------------------------------------------------------------------
ajoo>>
更正一下,没有看清楚robbin的上下文就胡乱评价了. 该死.
我完全同意robbin的关于loginUser的设计方法.
如果只有用户存在不存在的简单情况,自然用返回值多快好省.
但是,当可能的错误很多的时候,比如:
用户不存在,
用户存在但是被封
密码错误
等等等等, 自然是用exception更好.
用exception的好处是错误信息是结构化的,并且错误是可以任意扩展的.
比如,用户被删除了, 我甚至可以报告用户被删除了几天.
用户被封了,我甚至可以报告用户被哪个该死的斑竹封的,什么时候封的,封了几天等等.
这些,你拿返回值来玩?
这个exception是否是runtime的倒是值得商讨.
runtime的缺点是无法强制客户代码处理.
checked的缺点是如果加入了新的exception种类,客户代码必须马上改动, 如果中间有很多层,就要层层上报,即使这个exception暂时可能不会出现.
(比如系统封人制度还没有启动)
各有利弊. 一般来说我会让UserNotExistException之类的作为checked exception, 一些不那么重要的exception也许就可以作为runtime.
---------------------------------------------------------------------------------------
robbin
使用Checked Exception还是UnChecked Exception的原则,我的看法是根据需求而定。
如果你希望强制你的类调用者来处理异常,那么就用Checked Exception;
如果你不希望强制你的类调用者来处理异常,就用UnChecked。
那么究竟强制还是不强制,权衡的依据在于从业务系统的逻辑规则来考虑,如果业务规则定义了调用者应该处理,那么就必须Checked,如果业务规则没有定义,就应该用UnChecked。
还是拿那个用户登陆的例子来说,可能产生的异常有:
IOException (例如读取配置文件找不到)
SQLException (例如连接数据库错误)
ClassNotFoundException(找不到数据库驱动类)
NoSuchUserException
PasswordNotMatchException
以上3个异常是和业务逻辑无关的系统容错异常,所以应该转换为RuntimeException,不强制类调用者来处理;而下面两个异常是和业务逻辑相关的流程,从业务实现的角度来说,类调用者必须处理,所以要Checked,强迫调用者去处理。
在这里将用户验证和密码验证转化为方法返回值是一个非常糟糕的设计,不但不能够有效的标示业务逻辑的各种流程,而且失去了强制类调用者去处理的安全保障。
至于类调用者catch到NoSuchUserException和PasswordNotMatchException怎么处理,也要根据他自己具体的业务逻辑了。或者他有能力也应该处理,就自己处理掉了;或者他不关心这个异常,也不希望上面的类调用者关心,就转化为RuntimeException;或者他希望上面的类调用者处理,而不是自己处理,就转化为本层的异常继续往上抛出来。
-----------------------------------------------------------------------------------
ajoo>>
今天和workmate也有了关于异常的争论.
问题是这样:
我们需要实现一个根据一些规则验证url输入的正确性.
我的workmate设计成这样:
bool validateUrl(HttpServletRequest);
我说: 你只能判断输入是否正确, 却不能说哪里出错啊. 为什么不用exception呢? 不管有什么错误, 用exception表示出来, 什么信息都不会丢失.
他说: exception不好. 因为exception不应该参与正常control flow.
我说: 这是你自己的意见. 看你怎么定义control flow了.
他说, 90%的人都这样认为.
我说, 返回bool失去了对错误的fine control.我们只知道是否错了, 不知道错在哪里.
他说, 我们可能不一定需要fine control.
然后争论不休.
最后, 我问他, 那么你怎么告诉别人到底出了什么错呢?
他说: 我可以提供一个getError()函数嘛.
我说: 那么, 你的getError()是否要重新validate一遍输入呢?
他说:那... 我可以返回String
String validateUrl(...);
我说, 光string怎么够呢? 万一我需要在html上面显式错误信息, 我需要格式化的, 如果你的error message有回车, 你还要换成<br>呢.
他说, 不用担心, 我会处理br的. (估计是自己把回车替换成<br>吧)
唉, 我还没敢说, 万一我们需要对同一个错误生成不同的东西呢? 比如, 在数据库里log东西啦; 在html上用各种不同颜色,字体显式不同级别的错误; 给mainframe发送xml信息之类的.
他肯定会说: 没那么复杂的.
我说: 如果你throw exception, adapt成bool是举手之劳. 而如果你返回bool,则不可能转换成throw exception.
反正,这老哥本着一个:不能用exception来处理control flow的教条, 就是不同意用exception.
没办法.
----------------------------------------------------------------------------------------
ajoo>>
无数人说异常不应该控制程序流程。
谁仔细想过为什么吗?只怕都是人云亦云罢了。
知道,异常效率低嘛。可是程序流程不见得就是都要高效率的呀。
要真是效率决定一切,java程序员都去要饭得了,连c++扇子们都知道什么2/8原则,你们这里拿效率这么个鸡毛还当令箭耍什么劲?
没人什么地方都用异常。但是有些场合用异常就是方便,错误种类可扩展,错误信息详细,错误处理结构化,可以集中处理错误,不复杂化函数接口等等等等,这些都是用异常表达部分程序逻辑的好处。
你说不应该控制程序流程,好办。给个替代品啊。
Java代码
UserInfo login(String username, String pwd);
throws AuthencationException;
UserInfo login(String username, String pwd);
throws AuthencationException;
我这里如果login失败,用异常清晰简单。您给个其它的好用的解决方案先?
也不知道哪个弱人脑子都不过就给出这么个教条来。scheme还有continuation呢,那可是超级异常,不是一样用来处理程序流程?
具体情况具体分析,哪个方案最好用就用哪个,哪来那么多教条?
----------------------------------------------------------------------------------------
checked Exception只不过实现了一个自动文档化的功能,再就是提醒调用者去处理这个错误。
但是,为了这点好处把方法签名和exception绑在一起,其实是个得不偿失的错误。这会使接口无谓复杂化,还增加了代码的耦合程度。
举个例子来说,比如有一个接口I 的某个方法F throws ExceptionA,它的一个实现类里面,F方法里实现里调用了一个类的方法,这个类的方法throws Exception B,这个时候,如果你有三种选择
1、把Exception B用catch 吃掉
2、改变接口的声明,这个显然行不通
3、catch之后抛出一个unchecked Exception,Exception B就这样被强暴了,变成了一个unchecked Exception。
可见,checked Exception 如果没有unchecked Exception的帮忙,连最基本的任务都做不好,这个小小的例子,已经充分证明了checked Exception自身就不是一个完备的异常体系,只不过是当时设计者头脑一发热,做出了一个自以为漂亮的愚蠢设计。
C#取消掉checked Exception,完全是合理的。
------------------------------------------------------------------------------------------
robbin>>
异常类层次设计的不好带来的结果就是非常糟糕,例如JTA的异常类层次,例如EJB的异常类层次,但是也有设计的很好的,例如Spring DataAccessException类层次结构。
用设计糟糕的异常类层次来否定异常这个事物,是极度缺乏说服力的,就好像有人用菜刀砍了人,你不能否定这把菜刀一样。
这个帖子这么长了,该讨论的问题都讨论清楚了,总结也总结过n遍了,所以我早就没有兴趣再跟帖了。
实际上,这个讨论中隐含两个不断纠缠的话题:
1、checked ,还是unchecked异常?
2、用自定义的方法调用返回code,还是用异常来表达不期望各种的事件流
经过这么长的讨论,我认为结论已经非常清楚:
1、应该适用unchecked异常,也就是runtimeexception,这样可以让无法处理异常的应用代码简单忽略它,让更上层次的代码来处理
2、应该适用异常来表达不期望的各种事件流
事实上,你们去看一下现在Spring,Hibernate3都已经采用这种方式,特别是Spring的DataAccessException异常层次设计,是一个很好的例子。即使用RuntimeException来表达不期望的各种事件流。
-----------------------------------------------------------------------------------------
第一部分 选择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干脆利落了!
上面的最佳实践是引用前面回帖中那篇翻译的文章,再加上自己的一些理解写成。ajoo对“不要用异常处理业务流程”提出异议,我是无法辩驳的,毕竟水平不够。但我想,对于很多如我这样尚在初级阶段的程序员们,把前辈的话奉为教条也无可厚非吧? 至少这样会少犯错误吧,呵呵。
以上观点均是自己的理解,水平所限,请不吝指正。