浅谈.net和Java的异常类型设计

最近在自学Java，看到Java的检查型异常设计时，心中不免有些疑惑。疑惑使用检查型异常的必要性。注：本人现在从事的.net开发。C#在设计上借鉴了Java，但是，C# 并没有引入所谓的检查型异常。

在网上看到一些关于Java中是否该采用检查型异常的机制。真是众说纷纭，但是还是可以总结为，对这个设计的批评声更多。其实，我没有在真正项目中使用Java开发的经验，更没有过在方法签名中声明检查型异常的经验。但是，在使用了C#这个长时间以来，也没有觉得C#完全抛弃检查型异常带来怎样的不便和设计上的缺陷。

据说，C#的设计人员大都有很长时间的Java语言开发经验（怪不得从语法到机制上都是这么惊人的相似），也怪不得他们不引入检查型异常，估计是深受其苦吧。

我的感觉是，在.net的任何语言中引入检查型异常真的是弊大于利。面向对象中大家都知道一个原则——开放封闭原则。我们在设计的时候总是尽可能地考虑到扩展性，尽可能避免对已有实现的修改。当然，完全不修改几乎没有可能。但是我们倾向于“配置”。将一些改变配置在配置文件中，将耦合性降到最低。这样的好处有很多：可以用采用反射机制根据配置文件动态加载等。采用检查型异常的机制很明显，使配置的种种优点无法发挥作用。

一旦采用这种机制，方法的签名就将与各种异常类型产生紧密的耦合关系。一旦设计或者异常使用不当，需要进行改动，然后重新编译。特别是存在多层调用关系的时候，这样的修改关系就更为复杂。并且，也很难发挥面向对象的一些优势，比如多态。但是，有时确实需要提醒方法的调用者，某个方法确实存在很大的产生某种异常的风险（比如I/O、或者数据库异常），需要加以处理。这在C#中也做到了——是在调用类库方法的时候，智能提示产生的方法注释中告诉了客户程序，该方法将会产生哪些异常，需要注意捕获。说明C#中还是注意到了这一点。当然，如果你作为一个类库开发者或者开发人员，也可以这么做。

同时采用检查型异常，也很好地暴露了不必要的信息，有些意图从异常类中就可以加以揣测。这从某种程度上失去了信息的隐蔽性，但是，这个带来的好处应该远大于它的负面作用。采用检查型异常，可以很清楚地指示方法本身和主调方法遵循相应的规则。这个会使开发更加规范化。我想，这也是Java语言设计团队认为几乎一定要采用这种方式的原因吧。但是，我还是没有想到一个一定要使用的理由。

.net中的完全抛弃检查型异常，也会使得异常处理变得不那么实用和高效。因为，如果没有很好的文档作指导或者注释不规范，很容易你就丢失了对异常信息的掌握。但是，个人还是不觉得.net中引入检查型异常带来的好处更多，其实，如果在开发时文档规范化一些，就能够弥补缺失检查型异常的不足，但是，你知道的这是不可能的。

我觉得Java中也没有说应该完全抛弃检查型异常。存在的就是合理的。只要是适度使用。由于本人暂未有任何Java的项目经验，所以暂时不敢说有什么心得，期待在使用中能有点感悟。