我目前正在学习休眠模式下的代码编写以及一些博客。我碰到以下内容：
"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中的每个检查异常都做同样的事情。我知道我在这里缺少一些逻辑，但是请在这方面帮助我。 有人可以解释一下它的真正优势吗？
答案 0 :(得分：0)
这样做是为了使开发人员不必将所有有关Hibernate的操作都包装在try catch块中。
以下是一些为什么它是有用的功能的详细信息（详细信息here）：
异常及其处理方式总是在激烈的辩论中结束 Java开发人员之间。 Hibernate有一些不足为奇 值得注意的历史。在Hibernate 3.x之前，将引发所有异常 由Hibernate进行了检查异常，因此每个Hibernate API都被强制 开发人员捕获并处理异常。这个策略是 受JDBC的影响，JDBC也仅引发检查的异常。 但是，很快就知道这没有任何意义，因为 Hibernate抛出的所有异常都是致命的。在很多情况下，最好的 开发人员在这种情况下可以做的就是清理，显示错误 消息，然后退出应用程序。因此，从Hibernate开始 3.x，Hibernate抛出的所有异常都是未经检查的Runtime Exception的子类型，通常在单个位置处理。 应用。这也使任何Hibernate模板或包装器API 过时。
答案 1 :(得分：0)
为什么我们不能对Java中的每个已检查异常执行相同的操作
只要有帮助，我们绝对可以每次都做。就像您描述的情况一样。
有人可以解释一下它的真正优势吗？
您需要意识到SQLException确实对您的业务逻辑有用。答案是：不是真的。您几乎永远不会在代码中基于SQLException做出决定。如果您发现SQLException，则无法使用其信息（例如消息，代码）以某种方式分支您的业务逻辑。据我所知，唯一的例外是DuplicateKeyException，它可以用来确定已经存在一个值（例如登录名或电子邮件），因此您可以跳过一个选择以提高性能。
因此，您的DAO也无法使用它，您的服务也无法使用，因此您需要将其传播到控制器，捕获它，回滚事务并将错误消息呈现给用户。实际上，框架可以为您完成此任务。它们允许您以声明方式启动事务（@Transactional，如果异常从控制器中逃逸并使用某些ExceptionHandler呈现错误消息，则自动回滚。
因此您看到，您确实希望将这些异常从业务逻辑（DAO，服务，控制器）传播到框架。如果检查了这些异常，那么您将需要在链中的所有方法中声明throws。
这就是包装未检查的异常的好习惯。它们减少了代码中throws的样板。