为什么 Java 中要使用 Checked Exceptions

第一部分 选择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对“不要用异常处理业务流程”提出异议，我是无法辩驳的，毕竟水平不够。但我想，对于很多如我这样尚在初级阶段的程序员们，把前辈的话奉为教条也无可厚非吧？ 至少这样会少犯错误吧，呵呵。

以上观点均是自己的理解，水平所限，请不吝指正。

robbin的做法感觉很清晰，有层次感，抽象化

采用Exception来处理流程，然后由系统定义统一的异常处理框架，根据异常类名返回配置的信息（客户容易接受的异常信息和开发人员调式使用的触发异常的原因）。这篇文章不错。http://www.onjava.com/pub/a/onjava/2006/01/11/exception-handling-framework-for-j2ee.html?page=6&x-order=date

我们系统目前也是采取类似方式，不必到处try..catch,顶层统一处理业务异常，非常清晰。

我比较赞同robbin的做法,作为API设计者,必须区分框架的异常和业务逻辑的异常,作为框架的异常,API的使用者一般来说是不清楚怎么处理的,这部分,可以用Unchecked异常,但是如果是为了规范API使用者的行为,那么应该用checked 异常,并且告诉他们怎么处理此异常.
作为业务逻辑层面上的异常,我觉得在性能和业务系统异常信息之间做取舍.
在错误信息很重要的情况下,应该将异常设为checked的,这种异常就会参与到流程控制中,这样的异常作为usecase的一部分又有何不可呢?

Robbin,　这个没有什么好再讨论的了，　＂ 不要用Exception来作流程控制＂这个应该是ＪＡＶＡ程序员的基础知识，有时间建议你翻翻＜＜ＥＦＦＥＣＴＩＶＥ　ＪＡＶＡ＞＞，可能对你在异常处理这个问题上有帮助

马甲?这么晚发头一贴?

 
    咋能搞教条搞本本主义呢？
        异常控制流程很正常的
          在command,chain模式中，任何一个command抛出异常，整个执行序列都会终止
           举个例子， 如果没有权限，直接抛出 new Exception("no access");
            在这里，没有比直接抛出异常更优雅更漂亮更简单的方式了
         

就象幽雅的waltz...偏偏起舞.
ps:这个帖子太长了.太长了......

讨论这个问题，就跟讨论喜欢猫和狗哪个好养一样，根本没有绝对的答案....