Spring在JDBCTemplate中异常处理的实现

Question

我正在阅读一本 Spring 书来学习 Spring。在浏览了有关 JDBCTemplate 的部分后，我惊讶地发现 Spring 以不同的方式处理大多数 SQLException 异常。

例如，所有已检查异常都会转换为未检查异常。这样做到底有什么好处呢？

根据我的经验，大多数 SQL 异常都应该得到处理。例如，我们有一个与 Oracle PL/SQL 过程对话的应用程序。对 PL/SQL 过程的调用可能会返回 ORA-01403：未找到数据 异常。通常，您可以通过向用户显示错误消息来恢复这种异常。例如，搜索结果没有返回任何内容。

如果所有异常都未经检查，即 Spring 不会强迫您处理它们，那么 Spring 中将如何处理这种已检查异常？

我知道你可以捕获 RuntimeExceptions，但我非常喜欢你被迫处理检查异常的想法。将一些已检查异常转换为未检查异常有什么好处？

Answer 1

是的，应该处理异常，但是在 Spring 设计中，在比每个 DAO 方法更高的级别上。事实上，每个方法中都有 SQLException 处理的设计是不干净的复制粘贴设计，当您更改某些内容时，您必须在每个地方应用更改。

处理未检查异常的需求多种多样，也有不同的地方。其中之一是方面，例如，您可以将 Spring 的异常转换为您的异常（未捕获的异常不需要在方法签名中声明，因此这种转换非常优雅）。在REST方法中，您可以添加通用处理程序，将错误响应返回给调用者，并且您只需在一处编写异常处理。在基于JSF/JSP的技术中，您可以在发生错误时添加自己的错误页面。

Answer 2

有些人不喜欢检查异常，因为它们迫使您进行一些异常管理。我想春天的人就是这样的。

就我个人而言，我更喜欢按照预期的方式去做事情：

try {
    // execute some SQL
} catch (SQLException ex) {
    if (ex is an expected condition) {
        // deal with it: for example with a "no data found" condition
        // this might mean returning null, or throwing some kind of business exception, such as
        // NoEmployeeFoundException, or whatever
    } else {
        // this is a programming / environment error
        // throw as unchecked exception
        throw new RuntimeException(ex);
    }
}

当然，这种方法的缺点是工作量更大。好处是您已经在代码中明确说明了哪些是“预期”情况，哪些是不应该发生的。

Answer 3

这样做的好处是不必被迫捕获或申报它们。

我不认为在用户搜索期间找不到数据是异常的，特别是在 SQL 级别。将其转变为受检查异常相当于使用异常进行广义流控制。我认为应该避免使用反模式； YMMV。

许多与 SQL 相关的错误都与代码相关；在我看来，最好是在开发过程中快速失败。