为什么 Java 中要使用 Checked Exceptions

忍不住了！

看了Anders Hejlsberg的那篇文章，他说得太好了！

dlee：我觉得你没有完全明白大师得意思，呵呵。 你有点武断了。

要是方便的话，把这个例子拖出来给大家讲讲吧。我根本就不相信靠Java程序内部的调优能把系统性能提高2.5倍，因为这就意味着Java程序本身的执行时间在未调优之前至少占整体执行时间的60%，对于一个涉及I/O和RPC的J2EE应用来说这是不可想象的。所以我很有兴趣详细听听你的这个例子。

题外话：
优化的第一原则：不要优化
优化的第二原则：还是不要优化

Exception的处理是一种框架设计中的艺术，良好的Java框架一定会有良好的Exception机制。

我支持一部分只抛出RuntimeException的观点，不过这个也是有一定的原则的，有时候CheckedException可以更灵活的处理错误，而且还可以强制在框架下开发的系统处理错误。

CheckedException绝对是有必要的
举个例子,某个服务程序需要起一个线程不定时的完成某项操作,其实就是调用某个接口的方法,这个方法有异常,这个时候用RuntimeException根本就不合适,而是必须用CheckedException,调用者必须对此异常捕获处理

多一种让代码健壮的机制当然好，
但正所谓：上有政策下有对策
懒鬼们一个try{}catch(Exception e){}就搞定了

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,完全是合理的。

这只是懒鬼中的一种，另外一种根本就不去写 try{}catch(Exception e){}
此外由此带来的问题也来了，懒鬼的代码中是不是到处都分布着令人迷惑的try{}catch(Exception e){}那

先申明一下，本人是做业务应用系统的，个人觉得还是应该采取折中的做法，根据信息针对对象的不同采取不同的处理方式，对业务异常（如用户输入不正确或不符合业务流程定义）应返回相应的信息通知用户，供用户处理；对一些错误或其他不正常的情况就该直接忽略掉，告诉用户产生系统错误即可。

浏览了一遍，累。不过学习到很多东西，值得。

个人感觉，异常还是应该根据所处的层次来做不同处理。用不着一棒子打死，说非要这样，那样不可。

c#的异常设计只是考虑到大部分开发人员所犯的错误，以及单纯从代码的角度来看问题。未必就是完美的。

我比较认同robbin的说法，但有时亦要考虑到性能的问题，因为抛出Exception会比普通的JAVA语句消耗更多时间，有一次我们在WEBLOGIC控制台看到系统很频繁地做GC，并且每次GC回收内存很少。后来经查原来是代码中一个大循环中有多次Exception抛出，并用try{}catch(Exception e){}捕捉，造成性能下降。