### [观点](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 的硬件上运行，无论它们有多么古老。然而，如果发现有些“被检查的异常”挡住了路，尤其是发现你不得不去对付那些不知道该如何处理的异常，还是有些办法的。