只要你知道何时应使用检查异常，它就很棒。Java核心API未能遵循SQLException（有时甚至是IOException）的这些规则，这就是它们如此糟糕的原因。

检查异常应该用于预测的，但不可预防是错误的合理歇着。

未经检查的异常应用于其他所有内容。

我将为你详细说明这一点，因为大多数人都误解了这意味着什么。

可预测但无法预防：调用方在力所能及的范围内竭尽所能来验证输入参数，但其控制范围之外的某些情况导致操作失败。例如，你尝试读取文件，但是在你检查文件是否存在与读取操作开始之间有人将其删除。通过声明一个检查的异常，你可以告诉调用者预期该失败。
合理地恢复：没有任何必要告诉呼叫者预见他们无法恢复的异常。如果用户尝试从不存在的文件中读取，则调用者可以提示他们输入新的文件名。另一方面，如果该方法由于编程错误（无效的方法参数或错误的方法实现）而失败，则应用程序无法采取任何措施来解决执行中的问题。最好的办法是记录问题并等待开发人员稍后解决。
除非你抛出的异常满足以上所有条件，否则应使用Unchecked Exception。

在每个级别进行重新评估：有时，捕获已检查异常的方法不是处理错误的正确位置。在这种情况下，请考虑对你自己的呼叫者而言合理的选择。如果异常是可预测的，无法预防的并且使它们恢复正常，那么你应该自己抛出一个检查的异常。如果不是，则应将异常包装在未经检查的异常中。如果遵循此规则，你会发现自己将检查的异常转换为未检查的异常，反之亦然，具体取决于你所在的层。

对于已检查和未检查的异常，请使用正确的抽象级别。例如，具有两个不同实现（数据库和文件系统）的代码存储库应避免通过抛出SQLException或公开特定于实现的细节IOException。相反，它应该将异常包装在涵盖所有实现的抽象中（例如RepositoryException）。