JDBC SQL Exception vs Hibernate Exception(JDBC Exception)答案

【问题标题】：JDBC SQL Exception vs Hibernate Exception(JDBC Exception)JDBC SQL Exception vs Hibernate Exception(JDBC Exception)
【发布时间】：2018-12-03 09:39:43
【问题描述】：

我目前正在学习在 hibernate 中编写代码并浏览一些博客。我遇到了以下内容 - "JDBC API throws SQLException that is a checked exception, so we need to write a lot of try-catch block code. Most of the times it’s redundant in every JDBC call and used for transaction management. Hibernate wraps JDBC exceptions and throw JDBCException or HibernateException un-checked exception, so we don’t need to write code to handle it. "

我知道 SQL 异常是编译时异常，需要处理。但我没有得到包装检查异常并将其作为非检查异常抛出的概念。如果我们可以将检查转换为非检查异常检查异常，那么为什么我们不能对Java中的每个检查异常都做同样的事情。我知道我在这里遗漏了一些逻辑，但请帮我解决这个问题。另外，有人能解释一下这样做的真正优势吗？

【问题讨论】：

标签： java hibernate jdbc exception-handling

【解决方案1】：

这样做是为了让开发人员不必将您关于 Hibernate 的每一项操作都包装在 try catch 块中。

这里有一些详细信息为什么这是一个有用的功能（详细信息here）：

异常以及如何处理它们总是以激烈的争论告终 Java 开发人员之间。 Hibernate 有一些功能并不奇怪也有值得注意的历史。在 Hibernate 3.x 之前，所有异常都会抛出 Hibernate 是检查异常，所以每个 Hibernate API 都强制开发人员捕获和处理异常。这个策略是受 JDBC 影响，它也只抛出检查异常。然而，很快就发现这没有意义，因为 Hibernate 抛出的所有异常都是致命的。在许多情况下，最好的开发人员在这种情况下可以做的就是清理，显示错误消息，然后退出应用程序。因此，从 Hibernate 开始在 3.x 中，Hibernate 抛出的所有异常都是未经检查的 Runtime Exception 的子类型，通常在一个单独的位置处理应用。这也使得任何 Hibernate 模板或包装 API 过时了。

【讨论】：

【解决方案2】：

为什么我们不能对 Java 中的每个已检查异常都做同样的事情

我们绝对可以每次都这样做，只要它有用。就像您描述的案例一样。

有人能解释一下这样做的真正优势吗？

您需要意识到，SQLException 对您的业务逻辑有多大用处。答案是：不是。您几乎从不根据SQLException 在代码中做出决定。如果你发现SQLException，你就不能使用它的信息（例如消息、代码）来以某种方式分支你的业务逻辑。据我所知，唯一的例外是DuplicateKeyException，它可用于确定某个值（例如登录名或电子邮件）是否已经存在，因此您可以跳过一个选择以提高性能。

所以，你的 DAO 不能使用它，你的服务也一样，所以你需要将它传播到你的控制器，捕获它，回滚事务并向用户呈现错误消息。事实上，框架会为你做这件事。它们允许您以声明方式启动事务 (@Transactional)，如果异常从您的控制器逃逸，则自动回滚，并使用某些 ExceptionHandler 呈现错误消息。

因此，您确实希望将这些异常从您的业务逻辑（DAO、服务、控制器）传播到框架。如果检查了这些异常，则需要在链中的所有方法中声明 throws。

这就是包装未经检查的异常成为一种好习惯的地方。他们减少了代码中throws 的样板。

【讨论】：