Java JDBC Select 语句是否应该始终位于 Try-Catch 块中？

Question

将所有 Java JDBC Select 语句放在 try-catch 块中是一个好习惯吗？目前我编写的大部分代码都没有它。但是，我会尝试捕获插入/更新/删除。

注意：当前使用 Sprint Boot。

String sqlQuery = "Select productId, productName, productStartDate from dbo.product where productId = 5"

public getProductData() {
    ....
    List<Product> productList =  namedJdbcTemplate.query(sqlQuery, new ProductMapper());

Answer 1

由于这个问题被标记为spring-boot并且您正在使用 JdbcTemplate，所以我给您一个特定于 Spring 的答案。

Spring 的要点之一是避免开发人员使用样板文件。如果您发现自己重复添加内容，例如在执行 DML 的代码周围放置 try-catch 块，那么就会怀疑您没有做正确的事情。使用 Spring 在代码中添加您自己的 try-catch 并不总是错误的，但通常都是错误的。

在 Spring 参考文档https://docs.spring.io/spring-framework/docs/current/reference/html/data-access.html#jdbc中，有一个表格显示了开发人员的责任和 Spring 的责任。处理异常、处理事务和关闭 jdbc 资源都显示为 Spring 的职责。

SpringJdbc 会为你处理很多事情。它处理关闭 JDBC 资源并将连接返回到其池，并将异常从 SQLException 转换为未经检查的 DataAccessException 的层次结构。在 Spring 中，从封装在事务代理中的方法引发的未经检查的异常会导致事务回滚。如果您执行自己的 try-catch 逻辑，则可以防止在需要时发生回滚（如果您捕获异常并且代理永远不会看到它）。如果您不了解 Spring 在做什么，添加 try-catch 逻辑可能会导致问题。

异常确实需要在某个地方捕获。在 Spring Web 应用程序中，您可以设置一个异常处理程序来捕获从控制器层抛出的任何内容，以便您可以记录它。这样，正在进行的操作就会被干净地中断，当前事务会回滚，并且异常会以一致的方式得到处理。如果您有其他入口点，例如从队列中读取消息，那么它们将需要自己的异常处理程序。

抛出异常是为了逃避无法处理问题的当前上下文，并将控制权重新定位到安全的地方。对于大多数来自 JDBC 的异常，您无法修复它们，您只想让它被抛出，让当前事务回滚，然后让中央异常处理程序捕获并记录它。