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

反对 checked 异常

多年来，我始终无法得到一个体面的答复来回答以下问题：为什么一些开发人员如此反对 checked 异常？我进行了多次对话，阅读了博文，阅读了 Bruce Eckel 的观点（他是我见过的第一个对此发表反对意见的人）。

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

我进行的每一次对话都以同一个问题没有答案而告终……让我来设置一下：

一般来说（根据 Java 的设计），

• Error 用于永远不应该捕获的事情（VM 对花生过敏，而某人对此倒了一罐花生）
• RuntimeException 用于程序员做错的事情（程序员走出数组末尾）
• Exception（除 RuntimeException 外）用于程序员无法控制的事情（在写入文件系统时磁盘已满，进程的文件句柄限制已达，无法打开更多文件）
• Throwable 只是所有异常类型的父类。

我经常听到的一种说法是，如果出现异常，那么开发人员所能做的就是退出程序。

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

对于“我只退出”争论，我所说的即使你退出，你也需要显示一个合理的错误消息。如果你只是回避处理错误，那么当程序在没有明确指示原因的情况下退出时，你的用户不会太高兴。

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

我没有问题将 Main 用 catch(Exception)（或在某些情况下用 catch(Throwable) 包起来以确保程序能够正常退出 - 但我总是捕获我需要捕获的特定异常。这样做至少允许我显示一条适当的错误消息。

人们永远不会回答的问题就是这样：

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

如果答案是捕获 Exception，那么你也将错误程序员一样处理系统异常。那对我来说似乎是错的。

如果你捕获 Throwable，那么你正在以相同的方式处理系统异常和 VM 错误（诸如此类）。那对我来说似乎是错的。

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

我想说显示堆栈跟踪的程序是错误的。不喜欢 checked 异常的人不这么认为吗？

因此，如果你不喜欢 checked 异常，你能解释一下原因吗？并且回答那个没有得到回答的问题？

我并不是在寻找使用任一模型的建议，我寻找的是为什么人们从 RuntimeException 而不是从 Exception 扩展的原因，以及为什么他们捕获异常然后重新抛出一个 RuntimeException 而不是向他们的方法添加抛出。我希望了解不喜欢 checked 异常的动机。

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