如何处理和解析JPA持久性异常以向用户提供有意义的消息

Bil*_*mus 25 java parsing jpa exception-handling exception

我是JPA的新手,并希望在处理JPA的持久性异常时找到最佳实践,例如,可以由用户解决的唯一约束违规.有很多关于如何编写JPA应用程序的例子,但几乎没有关于如何处理由它们引发的异常的例子.:/

例如,注册用户,该人输入已被系统主动使用的电子邮件地址并获得约束违规:

try {
     em.persist(credentials);
} catch (javax.persistence.PersistenceException ex) {
Run Code Online (Sandbox Code Playgroud)

添加重复的电子邮件时会产生此错误:

WARNING: SQL Error: 0, SQLState: 23505
SEVERE: ERROR: duplicate key value violates unique constraint "EMAIL_UQ_IDX"
  Detail: Key (email)=(testuser@xyz.com) already exists.
Run Code Online (Sandbox Code Playgroud)

如何才能将有意义的答案反馈给用户?例如:Oops看起来好像有人正在使用该电子邮件地址,您确定以前没有注册吗?是否有内置工具来解析这个或者我是否需要在(可能是一系列)if语句中对异常消息运行正则表达式?

如果它被捕获在业务层上呢...那么将它踢到表示层的最佳实践是什么...就像我之前说过的那样,这样就可以为用户提供"好"的消息.


增加了对净度:正是这样的人都知道,我有,有,而且我仍然在寻找各种不同类型的持久性的异常,这里是一些我一直在做我没有用"try语句"包括研究上面包含的示例:

try {
     em.persist(credentials);
     } catch (javax.persistence.PersistenceException ex) {
         System.out.println("EXCEPTION CLASS NAME: " + ex.getClass().getName().toString());
         System.out.println("THROWABLE CLASS NAME: " + ex.getCause().getClass().getName().toString());
                Throwable th = ex.getCause();
         System.out.println("THROWABLE INFO: " + th.getCause().toString());
         Logger.getLogger(CredentialsControllerImpl.class
              .getName()).log(Level.INFO, "Credentials Controller "
                  + "persistence exception "
                      + "EXCEPTION STRING: {0}", ex.toString());
         Logger.getLogger(CredentialsControllerImpl.class
              .getName()).log(Level.INFO, "Credentials Controller "
                  + "persistence exception "
                      + "THROWABLE MESSAGE: {0}", th.getMessage());
         Logger.getLogger(CredentialsControllerImpl.class
              .getName()).log(Level.INFO, "Credentials Controller "
                  + "persistence exceptions "
                      + "THROWABLE STRING: {0}", th.toString());
     }
Run Code Online (Sandbox Code Playgroud)

:)

JB *_*zet 6

您通常不使用低级别例外来执行此操作.

相反,您明确地检查电子邮件是否可用(使用查询),并且仅在电子邮件不存在时才对其进行检查.

当然,也有可能是一个竞争条件,如果两个线程做同样的检查并行,但是这将是极为罕见的,并且数据库约束是有保证唯一性.