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 社区。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论 1 条评论