在Java（或任何其他具有检查异常的语言）中，当创建自己的异常类时，如何决定它是否应该检查或不检查？
我的直觉是，如果调用者能够以某种有效的方式恢复，则需要检查异常，而对于不可恢复的情况，则需要检查异常，但我对其他人的想法感兴趣。
只要您了解何时应该使用检查异常，检查异常就很棒。 Java 核心 API 未能遵循 SQLException（有时也没有 IOException）的这些规则，这就是它们如此糟糕的原因。
检查异常应该用于可预测, but 无法避免的错误是合理恢复.
未经检查的异常应该用于其他一切。
我会为你解释一下，因为大多数人都误解了这意味着什么。
-
可预见但不可预防：调用者已尽其所能来验证输入参数，但某些超出其控制范围的条件导致操作失败。例如，您尝试读取一个文件，但在您检查文件是否存在和读取操作开始之间，有人将其删除。通过声明受检查的异常，您可以告诉调用者预见到这种失败。
-
合理恢复：告诉调用者预见他们无法恢复的异常是没有意义的。如果用户尝试读取不存在的文件，调用者可以提示他们输入新文件名。另一方面，如果该方法由于编程错误（无效的方法参数或有错误的方法实现）而失败，则应用程序无法修复执行中的问题。它能做的最好的事情就是记录问题并等待开发人员稍后修复它。
除非你抛出的异常满足all对于上述情况，应该使用 Unchecked Exception。
在每个级别重新评估：有时捕获已检查异常的方法并不是处理错误的正确位置。在这种情况下，请考虑对于您自己的呼叫者来说什么是合理的。如果异常是可预测的、不可预防的并且可以合理地从中恢复，那么您应该自己抛出一个已检查的异常。如果没有，您应该将异常包装在未经检查的异常中。如果遵循此规则，您会发现自己将检查异常转换为未检查异常，反之亦然，具体取决于您所在的层。
对于已检查和未检查的异常，使用正确的抽象级别。例如，具有两种不同实现（数据库和文件系统）的代码存储库应避免通过抛出异常来暴露特定于实现的细节SQLException or IOException。相反，它应该将异常包装在跨越所有实现的抽象中（例如RepositoryException).
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
