为什么 SQLException 是一个检查异常[关闭]

Question

谁能想到SQLException 是一个已检查异常的合理原因？

是的，查询中可能存在语法错误
是的，连接可能已断开
是的，可能存在权限问题
等等等等等等等等等等

但几乎 100% 的时间（一旦您在生产环境中运行），没有任何问题。

如果出现问题，调用代码无法进行任何恢复，因此应该取消选中。

检查会在整个代码中创建大量敷衍的try catch 块，任何参与过使用 JDBC 的项目的人都会证明这一点。代码混乱很严重。

由于 SQL 的深奥性，你可能会得到一个 SQLException 的无数原因及其复杂性意味着你基本上无法恢复，除非异常是由临时网络问题引起的，但即使在同步调用中，你'无论如何都会沉没，因为您不能无限期地等待网络问题得到解决，因此您将不得不使交易失败。

通常，调用 SQL 如下所示：

try {
    // make some SQL call(s)
} catch {SQLException e) { 
    // log the exception
    return; // and give up
}

这样的代码没有任何价值。您无法采取任何合理的措施来恢复。您不妨让运行时异常冒泡——即 SQLException 应该是 runtime（未经检查的）异常。

Answer 1

几乎 100% 的时间没有任何问题 - 这仅限于您自己的观察，对其他系统一无所知。世界各地存在各种具有各种瓶颈的计算机系统。您的成功率几乎是 100%。其他人必须处理低得多的百分比。

常见的误解是考虑通过发生频率引入/删除检查异常。已检查的异常用作通信渠道。如您所知，每个方法都有其公共接口。这样，方法告诉我们它接受哪些参数以及它的主体中的代码的结果是什么。

当当前正在执行的方法无法兑现其承诺（例如返回值）时，它需要一种方法来告诉另一个方法出现问题并且无法执行预期的操作。但是怎么做呢？将消息作为返回值发送是行不通的，调用方法几乎没有机会区分正确的值和错误消息。并不是说某些方法具有 void 作为返回值。那么，当您无法遵守方法接口定义的承诺时，您会怎么做？好吧，你抛出一个异常（发送消息）。

如果您期望 ResultSet 并且没有建立与您的数据库的连接，您应该怎么做？返回空结果集？不，这告诉我们数据库是空的。返回空？好吧，这只会让问题变得更简单，让查找原因变得不清楚。

您可以使用该空结果集并将其作为对另一个数据库的另一个查询的一部分，从而使其不一致。

没有 SQLException，即使一个错误也可能导致数据不一致。

Answer 2

有几种方法可以解决已检查与未检查的困境。检查调用代码是否可以从异常中恢复是一种方法，但是我同意，这种方法并不能解释为什么SQLExcption 是一个已检查 异常。

Martin Fowler 在他的巨著“重构”中提供的另一个建议是验证是 calling 还是 called 方法的责任来进行检查，这可能导致异常。

如果 调用者 方法应该在调用 被调用 方法之前执行检查（例如确保参数不为空），那么如果尚未完成此检查显然是一个编程错误，然后调用方法应该抛出一个unchecked异常。

现在如果是被调用方法负责进行检查，因为只有这个方法可以知道如何执行这种检查，那么被调用方法抛出的异常应该被检查。

如果是SQLException，我想只有这个类可以知道：

• 查询中存在语法错误，因为这取决于数据库
• 连接已断开
• 存在权限问题

Answer 3

一个原因是一个方法应该抛出与该方法所做的抽象级别一致的异常。

因此，从数据库加载信息的方法不应引发SQLException，而应引发ResourceNotFoundException 或ResourceUnavailableException。

检查SQLException 是一种强制开发人员捕获异常并将其包装在这个新抽象级别中的方法。

这个论点取自 Joshua Bloch 的 Effective Java Second Edition（第 61 条：抛出适合抽象的异常）。

Answer 4

捕获异常使我们能够从异常情况中恢复，这是真的，但它们也允许我们做其他事情。

您无法从 SQLException 中恢复，因为您无法在运行时解决问题，但您可以做一些有用的事情：

• 记录异常以获取调试信息
• 回滚交易

您始终可以在更高级别（或更低级别，取决于视角）记录异常，但在调试时和审查代码时都会丢失一些语义价值。

如果你这样做：

try { ... }
catch(SQLException e) 
{ 
    SomeLogger.log(...);
    rollback();
    throw e;
}

稍后再回到这段代码，你会立即意识到 try 中的代码可能会失败，而无需在心里解析代码以确定它是否会失败。

您可以做的另一件事是确保已释放所有数据库资源，但我不确定这是否会立即发生。