Neal Gafter问了一个许多 Java 开发者都会问过的问题:“Java 语言和平台可以没有受检异常(Checked Exception)吗?”
他将反对受检异常的论点总结如下:
对受检异常的使用一直存有争议。许多人批评 Java 的受检异常,并把它们形容成软件工程中一次失败的试验。实际上,受检异常可能会导致 API 变得很复杂,程序跟异常检查代码混杂在一起,而这仅仅是为了通过编译器的编译。而另外一些人则认为受检异常是很好的语言特性,只是被误用了,甚至在 JDK 中也是这样。既然有这样糟糕的“专家”模范作用,我们还能期望普通的 Java 程序员能做得多好呢?
紧接着的讨论表明人们在这个话题上已两极分化,其中一些代表某种意见,比如以下观点来分别自于“匿名”、Christian Plesner Hansen、Henri 和 Cedric:
你不会知道自然状态的代码看起来是怎样的;人们捕捉根异常然后抛出六或七个特殊异常,或者使用许多异常来包含业务逻辑然后再抛出
Exception
,或者捕捉异常后再抛出错误代码,或者让 catch 块为空,或者捕捉NullPointerException
。
我是几个月前开始反对受检异常的。我报了一个 RFE(#6376696)并和 Sun 的相关人员讨论。他们对它几乎没什么兴趣,并最终将其标记为“不会 Fix”而关闭 [……] 受检异常就是不起作用。
我猜我是属于喜欢受检异常那一小拨人当中的一个 [……] 去掉受检异常会鼓励更糟糕的代码,因为当有错误出现时应用程序会直接当掉。而这样将会不再鼓励开发者对错误后果进行思考。
一定要把我算在认为受检异常对于构建大型 API 非常重要的那一边。当然,它们可能被误用,但未受检异常在许多地方同样也被过度使用了。
那么,受检异常还有用么?它究竟是一个并不是总被正确使用的好办法,还是一个应该终止的失败试验?
这也引出了一个更具普遍性的问题——从 Java 中去掉某些特性。如果我们一味地往语言中添加特性,而不删除其中的一些,那么语言只会变得越来越复杂。是不是有可能去掉某些特性,从而降低语言的复杂度,而不损害到语言本身呢?我们是不是应该去掉那些 deprecated 方法,并升级老的 API,而不用把向后兼容看得那么神圣不可侵犯呢?
继续追踪关于 Java 的未来的话题,请锁定 InfoQ 的 Java 社区。
评论 1 条评论