Java Spring CrudRepository 异常

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/23325413/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-13 21:56:16  来源:igfitidea点击:

Spring CrudRepository exceptions

javaspringspring-data

提问by gvdm

I have this Spring Data CrudRepositorywhich handles the CRUD operations on a DB.

我有这个 Spring DataCrudRepository来处理数据库上的 CRUD 操作。

@Repository
public interface IUserRepository extends CrudRepository<User, String> {

}

Useris the Entity of a User table of my DB. CrudRepositoryadds namely the following operations to the repository:

User是我的数据库的用户表的实体。CrudRepository即向存储库添加以下操作:

  • delete(String ID)
  • findOne(String ID)
  • save(User user)
  • delete(String ID)
  • findOne(String ID)
  • save(User user)

As stated in the documentation, the delete and find operations throw IllegalArgumentExceptionin case the given id is null while the save operation doesn't throw any exception.

文档中所述,删除和查找操作会IllegalArgumentException在给定 id 为空的情况下抛出,而保存操作不会抛出任何异常。

The problem is that the javadoc of the CrudRepository makes no mention about the other exceptions thrown by these operations. For example it doesn't tell that the delete(String ID)operation throws a EmptyResultDataAccessExceptionin case the provided ID is nonexistent in the DB.

问题是 CrudRepository 的 javadoc 没有提到这些操作引发的其他异常。例如,如果提供的 ID 在数据库中不存在,它不会告诉delete(String ID)操作抛出 a EmptyResultDataAccessException

In the javadoc of the save(User user)operation it's not clear which exceptions are thrown in case you insert a new User which breaks one data integrity constraint (on unique fields and foreign keys). Moreover it doesn't warn you whether you are writing a new or existent User: it just creates a new User or overwrites if existent (so it's a Insert + Update operation).

save(User user)操作的 javadoc 中,如果您插入一个新的 User 打破了一个数据完整性约束(在唯一字段和外键上),则不清楚抛出哪些异常。此外,它不会警告您是否正在编写新用户或现有用户:它只会创建一个新用户或在存在时覆盖(因此它是插入 + 更新操作)。

In a enterprise application I should be able to catch every throwable exception an operation can throw and I should read about that in the operation's javadoc.

在企业应用程序中,我应该能够捕获操作可能抛出的每个可抛出异常,我应该在操作的 javadoc 中阅读相关内容。

Do you know any clear documentation about CrudRepository exceptions?

你知道关于 CrudRepository 异常的任何明确的文档吗?

Thank you

谢谢

采纳答案by vtor

Spring has built-in exception translation mechanism, so that all exceptions thrown by the JPA persistence providers are converted into Spring's DataAccessException- for all beans annotated with @Repository (or configured).

Spring 具有内置的异常转换机制,因此 JPA 持久化提供程序抛出的所有异常都转换为 Spring 的DataAccessException- 对于所有用 @Repository 注释(或配置)的 bean。

There are four main groups -

有四个主要群体——

  • NonTransientDataAccessException- these are the exceptions where a retry of the same operation would fail unless the cause of the Exception is corrected. So if you pass non existing id for example, it will fail unless the id exists in the database.

  • RecoverableDataAccessException- these are the "opposite" of the previous one - exceptions which are recoverable - after some recovery steps. More details in the API docs

  • ScriptException- SQL related exceptions, when trying to process not well-formed script for example.

  • TransientDataAccessException- these are the exception when recovery is possible without any explicit step, e.g. when there is a timeout to the database, you are retrying after few seconds.

  • NonTransientDataAccessException- 这些是重试相同操作将失败的异常,除非异常的原因得到纠正。因此,例如,如果您传递不存在的 id,除非该 id 存在于数据库中,否则它将失败。

  • RecoverableDataAccessException- 这些是前一个的“相反” - 可以恢复的异常 - 经过一些恢复步骤。API 文档中的更多详细信息

  • ScriptException- SQL 相关异常,例如在尝试处理格式不正确的脚本时。

  • TransientDataAccessException- 这些是在没有任何明确步骤的情况下可以恢复时的异常,例如,当数据库超时时,您在几秒钟后重试。

That said, the ideal place to find documentation about all exceptions - is in the API itself - just go through the hierarchy of DataAccessException.

也就是说,查找有关所有异常的文档的理想位置 - 在 API 本身中 - 只需通过DataAccessException的层次结构即可。