“为什么运行时异常是不可恢复的？”

Question

在Java文档中，我看到了定义

“如果可以合理地期望客户端从异常中恢复，请将其设置为已检查的异常。如果客户端无法执行任何操作以从异常中恢复，请将其设置为未经检查的异常”

Unchecked Exceptions — The Controversy

我不清楚“恢复”的概念，这意味着什么？

而且，基于这个定义，为什么NumberFormatException无法恢复？我认为当发生此异常时，我们可以要求用户提供其他有效字符串来继续该程序。这是对的吗？

Answer 1

如果发生错误，则开发人员无法合理地从中恢复，应该是Error，例如VerifyError或NoMuchMethodError。如果出现这种情况，我认为应该是不可能的，我使用AssertionError

如果发生错误，开发人员可以从中恢复，尽管大多数开发人员不太可能知道如何处理异常，请使用RuntimeException，因为这并不会强制开发人员编写处理代码。

如果错误传递给调用者进行处理，即使大多数开发人员不知道如何从异常中恢复，即使他们这样做，也可能发现很难从该异常中恢复，可以使用例外。

你也可以创建一个Throwable或一个也被检查的直接子类，但是我只是用这个作为打印堆栈跟踪的简单方法，即明确它不是真正的错误。我建议避免像Throwable那样投掷，因为它令人困惑，而且不太可能正确处理。

在我们的代码库中，我们可能会说我们有效地使用Exception，并且在许多情况下写入调用者和被调用者，这是最有可能以有用的方式传递异常的机会。从来没有，通过后备恢复只占我们catch案件的19％，以及＃34;信号＆＃34; 6％的案例（A＆＃34; Signal＆＃34;在极少数情况下从调用堆栈深处传递一个已检查的异常）

总之，我们只设法以我认为检查异常的方式处理和恢复大约25％的异常/错误。我认为这是一个有价值的25％，但如果它更高，我会更高兴。

关于讨论我们处理异常的不同方式的完整帖子。 https://vanilla-java.github.io/2016/06/21/Reviewing-Exception-Handling.html

Answer 2

＆＃34;从＆＃34;恢复意味着异常不会停止你的程序，程序可以处理异常（借助try catch块）然后继续执行。

例如：

• 您正在创建一个程序来搜索员工数据库。
• 如果找不到特定的员工，那么您的计划应该是 从恢复（处理）它并允许用户寻找其他员工。
• 在这种情况下，您可以创建名为EmployeeNotFoundException的已检查例外
• Checked Exception会提示程序员处理它（通过try catch或使用throws）

为什么NumberFormatException成为未经检查的人：

• 首先，问题中提到的规则适用于用户定义的例外，而不适用于构建的例外情况。
• 它是一个未经检查的例外，因为它们表示编程错误。
• 在调用Integer.parseInt（）（例如）之前，可以知道输入字符串是否是有效的整数。因此，在尝试解析它之前应该执行此检查，而不是将此责任交给JVM。
• 您可以尝试捕获一段抛出未经检查的异常并尝试处理它的代码，但是出现未经检查的异常理想情况下会指出无法处理的问题。

Answer 3

检查异常背后的主要原因似乎是控制您想要处理错误的位置和时间。您可以使用try-catch立即处理它，或者只是声明方法throws并将其处理一个（或几个）更高级别。这也表明你可以从错误中恢复 - 为什么你还要关心你处理它们的位置？

NumberFormatException不是用户提供错误输入的错误，而是程序员没有预见到无效输入的可能性，因此无法恢复;它本质上是一个错误。

这里有一些关于例外情况的更深入的阅读：Checked vs unchecked exceptions

Answer 4

你是对的，你可以随时处理异常。出于同样的原因，存在try-catch块。但是处理可能导致代码的所有异常会导致繁琐的代码库。此外，还有更多场景，编程中的编程错误导致RuntimeException错误，而不是用户提供的无效输入。

最后意味着，如果要提供的功能无法对异常执行任何操作，并且无法处理异常，则异常将被标记为未经检查的异常。如果他想要处理未经检查的Exception以提供一些功能，那么它应该是程序员。