夜游长空

看到了tangrui回应的文章，我想说的是，可能我们对于异常处理的理解有些地方是不一样的。

1. 我认为异常处理绝不是消息传递。这点在《Effective Java》中是明确说明的。因为如果简单地把Exception看成是另外一种返回值，代码会越来越混乱，也不符合Exception这个名词的含义。会让人看不懂，是非常不好的程序风格。（只能说是不好的程序风格，不是错误，因为编译器允许这样做）

2. 我认为RuntimeException和Checked Exception是有明显区别的。在Java中，所有非RuntimeException都是Checked Exception，而在C#中，完全没有区别。可以从字面上理解，RuntimeException是不可预知的异常，比如：NullPointerException（所有可预知的Null，都应该被避免了，剩下的都是不可预知的），BufferOverflowException（鬼知道什么时候会出现~），ArithmeticException（除数是零，永远不能是零的数，突然成了零），等等。而非RuntimeException，都是可以预知的。比如说，IOException（极有可能失败的操作），ClassNotFoundException（也是很有可能出现），InterruptedException（线程被中断，有可能），还有一切与应用逻辑相关的Exception等等。可以认为，如果发生了RuntimeException，那么这个异常必然不是预期可能出现的，都是不可恢复的。所有Checked Exception都是设计者可以预期的异常，大多数是可以恢复的。

3. 所有的RuntimeException都不应该被catch，而所有的Checked Exception都应该被catch。RuntimeException发生，说明程序有问题；Checked Exception发生，说明程序进入了一个可预知的意外情况。如果对于可预知的异常不作处理，那么这个问题是基本的coding问题，应该让编译器检查。

4. 一个接口所可能抛出的所有的Checked Exception都应该是接口设计的一部分。如果只有文档说明，这个风险太大了。很可能漏掉了很重要的异常问题没有处理。我希望可以由编译器来替我承担一部分风险。

所以，我并不是认为C#的方式非常的不好，只是认为，它为开发大型应用，带来了一定的风险。尤其是维护上的。而Java这种方式，非常严谨，在编译阶段为开发人员发现了很多有可能出现的潜在问题，虽然有可能会多写一些代码（其实这些代码是不多写的，无论用Java和C#，最终都是要写这些代码的）。至于tangrui说的，开发小程序可以快速上手的问题，我觉得不存在。因为如果真的是要成为优秀的开发人员，严谨的开发习惯是必须的，并不应该在乎异常处理所带来的麻烦。可以这么说，异常处理是开发过程中，非常重要的一部分。

这个问题我也就说到这里了，表达了我对异常处理的理解。我现在学习工作都要用C++，不能再像Java一样靠编译器了~hehe