如何区分JPA中name为空/过长触发的DataIntegrityViolationException

当然可以实现！要区分name为空或长度超限这两种情况，核心是得从DataIntegrityViolationException里挖出底层的具体异常细节——毕竟这个异常只是JPA给出的上层包装，真正的约束违反原因藏在更底层的SQL异常里。

下面提供两种实用的实现思路，你可以根据自己的数据库选择合适的方式：

方法一：解析异常消息文本（通用但需适配数据库提示） #

大多数数据库在抛出约束违反异常时，会在消息里明确标注是哪个字段出了问题、违反了什么规则。我们可以遍历异常链找到最底层的SQLException，然后匹配消息内容：

@ControllerAdvice
public class ExceptionHandlers {

    @ExceptionHandler(DataIntegrityViolationException.class)
    public ResponseEntity<ErrorMessage> handleViolation(DataIntegrityViolationException e) {
        Throwable rootCause = e.getRootCause();
        String errorMsg = "data integrity violation"; // 默认提示
        
        if (rootCause instanceof SQLException) {
            String sqlMsg = ((SQLException) rootCause).getMessage();
            // 匹配数据库返回的提示文本，不同数据库可能 wording 略有不同，需调整
            if (sqlMsg.contains("'name' cannot be null") || sqlMsg.contains("column 'name' cannot be null")) {
                errorMsg = "null parameter";
            } else if (sqlMsg.contains("Data too long for column 'name'")) {
                errorMsg = "long parameter";
            }
        }
        
        return new ResponseEntity<>(new ErrorMessage(errorMsg), HttpStatus.BAD_REQUEST);
    }
}

方法二：使用SQL状态码（更稳定，需对应数据库错误码） #

不同数据库有标准化的SQL状态码，用这个判断比解析文本更可靠，不会因为数据库的语言设置（比如中文/英文提示）而失效。举两个常见数据库的例子：

• MySQL：非空约束违反是1048，字段长度超限是1406
• PostgreSQL：非空约束违反是23502，长度超限是22001

实现代码如下（以MySQL为例）：

@ControllerAdvice
public class ExceptionHandlers {

    @ExceptionHandler(DataIntegrityViolationException.class)
    public ResponseEntity<ErrorMessage> handleViolation(DataIntegrityViolationException e) {
        Throwable rootCause = e.getRootCause();
        String errorMsg = "data integrity violation"; // 默认提示
        
        if (rootCause instanceof SQLException) {
            String sqlState = ((SQLException) rootCause).getSQLState();
            
            switch (sqlState) {
                case "1048":
                    errorMsg = "null parameter";
                    break;
                case "1406":
                    errorMsg = "long parameter";
                    break;
            }
        }
        
        return new ResponseEntity<>(new ErrorMessage(errorMsg), HttpStatus.BAD_REQUEST);
    }
}

额外建议：提前参数校验（更优雅的方案） #

其实还有一种更推荐的方式——在请求进入业务逻辑前就做参数校验，不用等到JPA操作数据库时才抛出异常。你可以结合Spring的javax.validation注解，在Person类上直接定义校验规则：

@Entity
class Person {
    @Id @GeneratedValue
    private long id;
    
    @NotNull(message = "null parameter")
    @Size(max = 10, message = "long parameter")
    @Column(nullable = false, length = 10)
    private String name;
    
    // 构造器、getter/setter
}

然后在Controller的方法参数上添加@Valid注解触发校验：

@PostMapping("/persons")
public ResponseEntity<Person> createPerson(@Valid @RequestBody Person person) {
    // 业务逻辑
    personRepository.save(person);
    return new ResponseEntity<>(person, HttpStatus.CREATED);
}

最后新增一个处理MethodArgumentNotValidException的异常处理器，直接获取校验失败的提示信息：

@ExceptionHandler(MethodArgumentNotValidException.class)
public ResponseEntity<ErrorMessage> handleValidationErrors(MethodArgumentNotValidException e) {
    String errorMsg = e.getBindingResult().getFieldError().getDefaultMessage();
    return new ResponseEntity<>(new ErrorMessage(errorMsg), HttpStatus.BAD_REQUEST);
}

这种方式不仅性能更好（避免了数据库操作），而且代码逻辑更清晰，还能统一处理所有参数校验问题。

内容的提问来源于stack exchange，提问作者Johnyb