为什么 Java 中要使用 Checked Exceptions



关于 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
两位都是大师级的人物，观点的碰撞非常精彩。

我个人更倾向于 James Gosling 的观点，即稳定性更加重要。C++ 程序的后期维护成本远远高于 Java 程序，更不要说前期的开发成本了。Java 要担负企业级的核心应用（HA 24X7），没有这些系统级的保证是不可能的。C++、Delphi 都中没有 Checked Exceptions，所以 Anders 设计 C# 时也没有加 Checked Exceptions。当然我并不是说没有 Checked Exceptions 就一定不能写出稳定的程序（你说，我就是比你牛，我用汇编语言都能写出稳定的程序！），但是显然使用 Java 语言写出稳定的程序比用 C++ 更容易。Checked Exceptions 就是编程语言所提供的系统级保证，能否用好是你自己的问题了，并不象 Anders 说的那样严重。我觉得 Anders 大师对于企业级应用并没有太多的概念。James Gosling 看了 C# 的设计后觉得不过如此。当然这只是大师本人的观点，我们未必一定要接受了。

在看一些项目源码中，突然发现了异常的处理也是一门比较大的学问，其实处处都有学问，只是你是否留意而已。。好了，少点啰嗦，关于异常的处理，je上有个很精彩的讨论，我花了快一个钟时间才看完了，确实值得一看，帖子的网址：http://www.iteye.com/topic/2038 

  当然我这里写的，只是一个纯属的建议，大都是看了网上的帖子后，总结的。都是些前辈的经验。。下面开始吧。

——————————————————————————————————————————————

Java异常有三类：错误，运行时异常，检查型异常。

 

官方的观点是

第 39 条：最好为异常条件使用异常。也就是说，最好不为控制流使用异常。

第 40 条：为可恢复的条件使用检查型异常，为编程错误使用运行时异常。

第 41 条：避免不必要的使用检查型异常。

第 43 条：抛出与抽象相适应的异常。（使处理异常更直观）

在异常的使用上，专家的观点是很不一样的

C#作者Anders根本就忽略检查型异常。

Bruce Eckel，声称在使用 Java 语言多年后，他已经得出这样的结论，认为检查型异常是一个错误 —— 一个应该被声明为失败的试验。

——————————————————————————————————————————————

缺点：

缺点1，代码中包含了过多的catch，使得代码不清晰

缺点2，有时候捕捉的异常没有什么实际意义

缺点3，不够清晰的错误指示。

缺点4，过深的异常层次。

缺点4，性能。

——————————————————————————————————————————————

Eckel 提倡将所有的异常都作为非检查型的，并且提供将检查型异常转变为非检查型异常的一个方法，同时保留当异常从栈向上扩散时捕获特定类型的异常的能力

 

Rod Johnson ，他采取一个不太激进的方法。他列举了异常的多个类别，并且为每个类别确定一个策略。一些异常本质上是次要的返回代码（它通常指示违反业务规则），而一些异常则是“发生某种可怕错误”（例如数据库连接失败）的变种。Johnson 提倡对于第一种类别的异常（可选的返回代码）使用检查型异常，而对于后者使用运行时异常。在“发生某种可怕错误”的类别中，其动机是简单地认识到没有调用者能够有效地处理该异常，因此它也可能以各种方式沿着栈向上扩散而对于中间代码的影响保持最小（并且最小化异常淹没的可能性）。

——————————————————————————————————————————————

解决1：谨慎的抛出检查型异常。或者你认为，你可以处理它。否则，包装为运行时异常。

解决2：如果遵守1，2不是问题

解决3：异常不跨层，否则必须捕捉或者包装。

         比如持久层丢出的SalException，你或者丢弃/处理/包装（为运行时异常），或者重新包装为业务层异常。保持JEE层的独立和异常的清晰性。

         包装底层异常，保持异常链。

解决4：如果符合1，4也不是问题。再次强调，能捕捉就捕捉。

解决5：减少异常使用，减少层次。

http://www.iteye.com/topic/2038

http://zhxing.iteye.com/blog/374307

跨层异常流程:中断流程

错误，运行时异常，检查型异常。