Question

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

例如，所有已检查的异常都将转换为未经检查的异常。这有什么好处？

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

如果所有异常都未被检查，Spring会如何处理这种被检查的异常，即Spring不会强迫你处理它们？

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

Answer 1

是的，应该处理异常，但是在Spring设计中，在每个DAO方法的更高级别上。事实上，每种方法都存在SQLException处理的设计是不干净的复制粘贴设计，当你改变某些东西时，你必须在每个地方都应用这种改变。

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

Answer 2

利益不是被迫捕获或宣布它们。

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

许多与SQL相关的错误与代码有关; IMO最好快速失败 - 在开发过程中。

Answer 3

有些人不喜欢检查异常，因为它们会强制您进行一些异常管理。我猜春天的人都是这样的。

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

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);
    }
}

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

Spring在JDBCTemplate中实现异常处理

3 个答案: