在Java文档中，我看到了定义
"如果可以合理地预期客户端会从异常中恢复，则将其设为受检查的异常。如果客户端无法执行任何操作来从异常中恢复，请将其设为未经检查的异常"
未经检查的异常——争议 https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
我不太明白“恢复”这个概念，它是什么意思？
并且，基于这个定义，为什么NumberFormatException无法恢复？我认为当这个异常发生时，我们可以要求用户提供其他有效的字符串来继续程序。那是对的吗？
如果发生错误，开发人员无法合理地从中恢复，则应该是Error e.g. VerifyError or NoMuchMethodError。如果出现我认为不可能的情况，我会使用AssertionError
如果发生开发人员可能能够恢复的错误，尽管大多数开发人员不太可能知道如何处理异常，但可以使用RuntimeException因为这不会强迫开发人员编写处理代码。
如果一个错误被传递给调用者来处理，即使大多数开发人员不知道如何从异常中恢复，即使他们知道，可能会发现很难从该异常中恢复，也可以使用受检查的异常。
您还可以创建一个Throwable或也被检查的直接子类，但是我仅使用它作为打印堆栈跟踪的简单方法，即明确它不是真正的错误。我建议避免抛出诸如 Throwable 之类的东西，因为它很令人困惑并且不太可能被正确处理。
在我们的代码库中，我们可以说我们有效地使用了 Exception，并且在许多情况下都编写了调用者和被调用者，这是能够以有用的方式传递异常的最佳机会。尽管如此，通过后备恢复仅占我们的 19%catch案例中，“信号”占案例的 6%（“信号”在极少数情况下会从调用堆栈深处传递已检查的异常）
总之，我们只能按照我认为检查异常的预期方式处理和恢复大约 25% 的异常/错误。我认为 25% 很有价值，但如果能更高我会更高兴。
完整的帖子讨论了我们处理异常的不同方式。https://vanilla-java.github.io/2016/06/21/Reviewing-Exception-Handling.html https://vanilla-java.github.io/2016/06/21/Reviewing-Exception-Handling.html
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
