何时选择已检查和未检查的例外 [英] When to choose checked and unchecked exceptions
问题描述
在Java（或任何其他具有已检查异常的语言）中，在创建自己的异常类时，如何确定是应该选中还是取消选中？
In Java (or any other language with checked exceptions), when creating your own exception class, how do you decide whether it should be checked or unchecked?
My本能是指在调用者可能以某种富有成效的方式恢复的情况下将调用已检查的异常，其中未经检查的异常将更多地用于不可恢复的情况，但我会对其他人的想法感兴趣。 / p>
My instinct is to say that a checked exception would be called for in cases where the caller might be able to recover in some productive way, where as an unchecked exception would be more for unrecoverable cases, but I'd be interested in other's thoughts.
推荐答案
选中的例外情况很好，只要您了解何时应该使用它们。 Java核心API无法遵循SQLException的这些规则（有时候对于IOException），这就是它们如此糟糕的原因。
Checked Exceptions are great, so long as you understand when they should be used. The Java core API fails to follow these rules for SQLException (and sometimes for IOException) which is why they are so terrible.
检查异常应该用于可预测，但不可预防的错误合理地从恢复。
Checked Exceptions should be used for predictable, but unpreventable errors that are reasonable to recover from.
未经检查的例外应该用于其他所有事情。
Unchecked Exceptions should be used for everything else.
我会为你解决这个问题，因为大多数人误解了这意味着什么。
I'll break this down for you, because most people misunderstand what this means.
- 可预测但不可预防：来电者尽其所能验证输入参数，但有些情况不在他们的控制导致操作失败。例如，您尝试读取文件，但有人在您检查文件是否存在以及读取操作开始的时间之间删除它。通过声明已检查的异常，您告诉呼叫者预测此故障。
- 合理恢复：没有必要告诉呼叫者预测他们的例外情况无法从中恢复。如果用户尝试从不存在的文件中读取，则调用者可以提示他们输入新文件名。另一方面，如果该方法由于编程错误（无效的方法参数或错误的方法实现）而失败，那么应用程序无法在执行中期解决问题。它能做的最好的就是记录问题并等待开发人员稍后修复它。
- Predictable but unpreventable: The caller did everything within their power to validate the input parameters, but some condition outside their control has caused the operation to fail. For example, you try reading a file but someone deletes it between the time you check if it exists and the time the read operation begins. By declaring a checked exception, you are telling the caller to anticipate this failure.
- Reasonable to recover from: There is no point telling callers to anticipate exceptions that they cannot recover from. If a user attempts to read from an non-existing file, the caller can prompt them for a new filename. On the other hand, if the method fails due to a programming bug (invalid method arguments or buggy method implementation) there is nothing the application can do to fix the problem in mid-execution. The best it can do is log the problem and wait for the developer to fix it at a later time.
除非您是例外投掷符合所有上述条件时应使用未经检查的例外。
Unless the exception you are throwing meets all of the above conditions it should use an Unchecked Exception.
在每个级别重新评估：有时候捕获已检查异常的方法不是处理错误的正确位置。在这种情况下，请考虑对您自己的呼叫者来说什么是合理的。如果异常是可预测的，不可避免且合理的，他们可以从那时恢复，你应该自己抛出一个检查异常。如果没有，则应将异常包装在未经检查的异常中。如果您遵循此规则，您会发现自己将已检查的异常转换为未经检查的异常，反之亦然，具体取决于您所在的层。
Reevaluate at every level: Sometimes the method catching the checked exception isn't the right place to handle the error. In that case, consider what is reasonable for your own callers. If the exception is predictable, unpreventable and reasonable for them to recover from then you should throw a checked exception yourself. If not, you should wrap the exception in an unchecked exception. If you follow this rule you will find yourself converting checked exceptions to unchecked exceptions and vice versa depending on what layer you are in.
对于已检查和未检查的异常，使用正确的抽象级别。例如，具有两个不同实现（数据库和文件系统）的代码存储库应避免通过抛出 SQLException 或 IOException 。相反，它应该将异常包装在跨越所有实现的抽象中（例如 RepositoryException ）。
For both checked and unchecked exceptions, use the right abstraction level. For example, a code repository with two different implementations (database and filesystem) should avoid exposing implementation-specific details by throwing SQLException or IOException. Instead, it should wrap the exception in an abstraction that spans all implementations (e.g. RepositoryException).
这篇关于何时选择已检查和未检查的例外的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
