如何处理在finally块中关闭连接时引发的异常？

Question

所以，场景是我正在做一些数据库操作，最后提交/回滚，然后连接关闭。但是连接关闭也会抛出SQLException。

在这种情况下，最好的方法是什么？

1. 捕获并记录它。
2. 捕获并抛出异常，以便调用函数可以处理它

在#1的情况下，调用函数永远不会知道出了问题。

Answer 1

我想你自己回答了：2.接住并抛出异常，以便调用函数可以处理它，这有帮助吗？

Answer 2

这被称为“封装”的面向对象基本规则之一所涵盖，该规则坚持我们不会将类的内部状态暴露给其协作者。这对问题的影响是，一个适当分解的类不应该将SQL异常传播到使用它的类（通常在更高层）。

确切地说，限制是您不会将SQL类公开到更高的一层，并且在三层应用程序的情况下，人们希望更高的一层包含业务逻辑。业务逻辑不应该知道任何关于SQL的信息——这就是数据库/存储库层的用途。因此，所有SQL异常都应该在层边界处进行转换。

这种方法的好处是您可以交换存储库的实现，而无需更改系统的其余部分。理论上，您可以用SQL的方法替换SQL，并且存储库的客户端永远不需要知道。即使您在运行时这样做了。

在Java中，我们通常通过在每层创建单独的jar文件（maven模块）来确保不会将状态（如SQL感知）错误地暴露到不同的层，以便控制层的依赖关系。如果我们不将SQL库添加为业务逻辑库的依赖项，那么如果我们在该层中引用它，就会出现编译错误。

因此，为了充分回答您的问题，存储库层应该处理数据库连接，该层的客户端，即业务逻辑，不需要知道SQL错误。您应该捕获异常并决定在数据库代码中如何处理它。如果您不能做出有效的决定，那么您应该为更高级别的抽象（业务逻辑）创建一个异常来处理。您如何处理特定问题是特定于应用程序的；如果tx已提交，并且您正在docker容器中运行单线程微服务，您可能只是记录问题并终止容器，但如果您在需要恒定数据库连接的GUI应用程序中，您可能会向业务逻辑层抛出自定义“连接”异常，这可能会生成一个异常，该异常被用户交互界面捕获，以向用户显示问题以供解决。