🔥码云GVP开源项目 12k star Uniapp+ElementUI 功能强大 支持多语言、二开方便! 广告
### [观点](https://lingcoder.gitee.io/onjava8/#/book/15-Exceptions?id=%e8%a7%82%e7%82%b9) 首先,值得注意的是 Java 有效的发明了“被检查的异常”(很明显是受 C++ 异常说明的启发,以及异常说明通常并不烦扰 C++ 程序员的事实),但是,这还只是一次尝试,目前还没有别的语言选择复制这种做法。 其次,仅从示意性的例子和小程序来看,“被检查的异常”的好处很明显。但是当程序开始变大的时候,就会带来一些微妙的问题。当然,程序不是一下就变大的,这有个过程。如果把不适用于大项目的语言用于小项目,当这些项目不断膨胀时,突然有一天你会发现,原来可以管理的东西,现在已经变得无法管理了。这就是我所说的过多的类型检查,特别是“被检查的异常"所造成的问题。 看来程序的规模是个重要因素。由于很多讨论都用小程序来做演示,因此这并不足以说明问题。一名 C# 的设计人员发现: > “仅从小程序来看,会认为异常说明能增加开发人员的效率,并提高代码的质量;但考察大项目的时候,结论就不同了-开发效率下降了,而代码质量只有微不足道的提高,甚至毫无提高”。 谈到未被捕获的异常的时候,CLU 的设计师们认为: > “我们觉得强迫程序员在不知道该采取什么措施的时候提供处理程序,是不现实的。” 在解释为什么“函数没有异常说明就表示可以抛出任何异常”的时候,Stroustrup 这样认为: > “但是,这样一来几乎所有的函数都得提供异常说明了,也就都得重新编译,而且还会妨碍它同其他语言的交互。这样会迫使程序员违反异常处理机制的约束,他们会写欺骗程序来掩盖异常。这将给没有注意到这些异常的人造成一种虚假的安全感。” 我们已经看到这种破坏异常机制的行为了-就在 Java 的“被检查的异常”里。 Martin Fowler(UML Distilled,Refactoring 和 Analysis Patterns 的作者)给我写了下面这段话: > “...总体来说,我觉得异常很不错,但是 Java 的”被检查的异常“带来的麻烦比好处要多。” 我现在认为 Java 的重要进步是统一了错误报告模式,所有错误都用异常来报告。这没有在 C++ 中发生,原因是为了向后兼容 C ,直接忽略错误的旧模式在 C++ 中依然是可用的。如果想使用异常,可以始终用异常来报告,如果不想这样做,异常可以抛到最高的级别(比如控制台)。当 Java 修改 C++ 的模式来让异常成为报告错误的唯一方式时,受检查的异常的额外限制可能就变得不那么必要了。 过去,我曾坚定地认为“被检查的异常”和强静态类型检查对开发健壮的程序是非常必要的。但是,我看到的以及我使用一些动态(类型检查)语言的亲身经历告诉我,这些好处实际上是来自于: 1. 不在于编译器是否会强制程序员去处理错误,而是要有一致的、使用异常来报告错误的模型。 2. 不在于什么时候进行检查,而是一定要有类型检查。也就是说,必须强制程序使用正确的类型,至于这种强制施加于编译时还是运行时,那倒没关系。 此外,减少编译时施加的约束能显著提高程序员的编程效率。事实上,反射和泛型就是用来补偿静态类型检查所带来的过多限制,在本书很多例子中都会见到这种情形。 我已经听到有人在指责了,他们认为这种言论会令我名誉扫地,会让文明堕落,会导致更高比例的项目失败。他们的信念是应该在编译时指出所有错误,这样才能挽救项目,这种信念可以说是无比坚定的;其实更重要的是要理解编译器的能力限制。在[http://MindView.net/Books/BetterJava](http://mindview.net/Books/BetterJava)上的补充材料中,我强调了自动构建过程和单元测试的重要性,比起把所有的东西都说成是语法错误,它们的效果可以说是事半功倍。下面这段话是至理名言: > 好的程序设计语言能帮助程序员写出好程序,但无论哪种语言都避免不了程序员用它写出坏程序。 不管怎么说,要让 Java 把“被检查的异常”从语言中去除,这种可能性看来非常渺茫。对语言来说,这个变化可能太激进了点,况且 Sun 的支持者们也非常强大。Sun 有完全向后兼容的历史和策略,实际上所有 Sun 的软件都能在 Sun 的硬件上运行,无论它们有多么古老。然而,如果发现有些“被检查的异常”挡住了路,尤其是发现你不得不去对付那些不知道该如何处理的异常,还是有些办法的。