JDBC异常与Hibernate异常(JDBC异常)

Question

我目前正在学习使用hibernate编写代码，并浏览了一些博客。

我知道SQL异常是一个编译时异常，需要是handled.But --我不知道包装检查异常并将其作为非检查的exception.If抛出的概念，我们可以将检查异常转换为非检查异常，那么为什么我们不能对Java.I中的每个检查异常做同样的操作呢?我知道这里缺少一些逻辑，但是请您在this.Also中帮助我，有人能解释一下它的真正优势吗？

Answer 1

这样，开发人员就不必将所有有关Hibernate的操作都包装在try catch块中。

下面是为什么这是一个有用的特性( details 这里)的一些细节：

异常和应该如何处理它们总是在Java开发人员之间激烈的争论中结束。不足为奇的是，Hibernate也有一些值得注意的历史。在Hibernate 3.x之前，Hibernate引发的所有异常都会被检查异常，因此每个Hibernate API都迫使开发人员捕获和处理异常。这个策略受到JDBC的影响，JDBC也只抛出检查过的异常。但是，很快就清楚了，这是没有意义的，因为Hibernate引发的所有异常都是致命的。在许多情况下，开发人员在这种情况下所能做的最好的事情就是清理、显示错误消息并退出应用程序。因此，从Hibernate 3.x开始，Hibernate引发的所有异常都是未检查的运行时异常的子类型，该异常通常在应用程序中的单个位置处理。这也使得任何Hibernate模板或包装API都过时了。

Answer 2

为什么我们不能对Java中的每一个检查异常都这样做呢？

我们绝对可以做到每一次，只要它是有用的。就像你描述的那个案子一样。

有人能解释一下这件事的真正好处吗？

您需要认识到，SQLException对于您的业务逻辑到底有多有用。答案是:不完全是。您几乎从不根据SQLException在代码中做出决定。如果捕捉到SQLException，则不能使用它的信息(例如消息、代码)以某种方式将业务逻辑分支。我所知道的唯一例外是DuplicateKeyException，它可以用来确定一个值(例如登录名或电子邮件)已经存在，因此您可以跳过一个选择来提高性能。

因此，您的DAO不能使用它，您的服务也是如此，所以您需要将它传播到您的控制器，捕获它，回滚事务并向用户呈现错误消息。事实上，框架为您提供了这样的功能。它们允许您以声明方式启动事务(@Transactional)，如果某个异常从控制器转出并使用某些ExceptionHandler呈现错误消息，则可以自动回滚。

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

这就是对未检查异常的包装成为良好做法的地方。它们减少了代码中throws的样板。