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



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



 

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

 

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

 

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

 

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

 

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

 

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

 

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



版权声明:本文为博主原创文章,未经博主允许不得转载。