为什么开发人员反对 Java 中的检查异常？

反对 checked 异常

许多年来，我无法对以下问题获得一个满意的答案：为什么有些开发者如此反对 checked 异常？我进行了许多对话、阅读博客文章，阅读了 Bruce Eckel 的观点（他说出了反对 checked 异常的第一人）。

我目前正在编写一些新代码，并且非常注意处理异常的方式。我试图了解“我们不喜欢 checked 异常”的人群的观点，但我仍然无法理解。

我所进行的每一次对话最终都是以同样的尚未解决的问题结束的……让我来阐述一下：

一般而言（根据 Java 的设计），

• 错误是用于永远不应该捕获的事情（VM 对花生过敏，有人不小心在它上面撒了一罐花生）
• 运行时异常是用于程序员做错的事情（程序员越界使用数组）
• 异常（运行时异常除外）是用于超出程序员控制的事情（文件系统中写入文件时磁盘已满，进程的文件句柄数量限制已达到，无法再打开文件）
• 可抛出对象只是所有异常类型的父类。

我经常听到的一个论点是，如果发生了异常，那么开发人员所要做的就是退出程序。

我听到的另一个常见论点是，checked 异常使重构代码变得更加困难。

对于“我就退出”的论点，即使你退出，仍然需要显示一条合理的错误消息。如果你只是在错误处理方面拖延，那么你的用户在程序不带明确退出原因退出时不会过于高兴。

对于“它使重构变得困难”的人群，这表明未选择适当的抽象级别。与其声明一个方法抛出 IOException，应将 IOException 转换为更适合正在进行的事情的异常。

我不会针对包装 Main 的 catch(Exception)（或在某些情况下为 catch(Throwable) 而抓狂，它可以确保程序能优雅退出，但我总要捕获我需要的特定异常。这样做使我能够至少显示一个合适的错误消息。

人们永远不回答的问题是：

如果你抛出 RuntimeException
子类而不是 Exception
子类，你怎么知道
应该捕获什么？

如果答案是捕获 Exception，那么你还在以与系统异常相同的方式处理程序员错误。那在我看来是错误的。

如果捕获 Throwable，那么你还在以相同的方式处理系统异常和 VM 错误（及类似错误）。那在我看来是错误的。

如果答案是只捕获你知道抛出的异常，那么你如何知道抛出了哪些异常？当程序员 X 抛出一个新异常并忘记捕获它时会发生什么？在我看来，这很危险。

我想说，会显示堆栈跟踪的消息是错误的。不喜欢 checked 异常的人不觉得这样吗？

所以，如果你不喜欢 checked 异常，你能否解释一下为什么不，而且请回答那个没有得到回答的问题。

我并不是在寻求关于何时使用这两种模型的建议，我正在寻找 为什么 人们从 RuntimeException 扩展而不是从 Exception 扩展，以及/或者他们在捕获异常后重新抛出 RuntimeException 而不是向方法添加 throws 的原因。我希望了解人们不喜欢 checked 异常的动机。

以上是为什么开发人员反对 Java 中的检查异常？的详细内容。更多信息请关注PHP中文网其他相关文章！