springboot 常见错误 springboot test报错

在春季Boot应用中，当DTO字段同时使用@NotNull和依赖字段的@AssertTrue进行验证时，可能会遇到HV000090错误，即使因为字段为null，@AssertTrue方法仍会被调用。本文将详细讨论此问题，并提供一种简洁有效的方法的解决方案：在@AssertTrue方法内部增加空值检查，以确保自定义验证逻辑仅在关联字段非空时执行，从而避免不必要的异常，优化数据校验流程。问题行为描述：@NotNull与@AssertTrue的默认冲突

在使用Java Bean验证（JSR 380）进行数据校验时，开发者通常会结合使用多个注解来确保数据的错误和业务逻辑正确性。@NotNull用于检查字段是否为null，而@AssertTrue则允许定义一个返回布尔值的自定义方法，以实现更复杂的验证逻辑。

然而，一个常见的问题是，当一个字段同时被@NotNul时l 修饰，并且有一个@AssertTrue方法依赖于该字段的值时，即使@NotNull验证失败（即字段为null），@AssertTrue方法仍然可能被执行。这会导致在@AssertTrue方法中尝试访问一个空值字段时，抛出NullPointerException，然后被Hibernate Validator捕服为HV000090：无法访问属性/方法错误。

例如，考虑以下DTO结构：import lombok.Data；import javax.validation.constraints.AssertTrue；import javax.validation.constraints.NotNull；@Datapublic class Dto { @NotNull(message = quot；anInt 不能为空quot；) private Integer anInt； @AssertTrue(message = quot；anInt必须是123或999quot；) public boolean isIntCustomValid() { // 当anInt为null时，这里会抛出NullPointerException return anInt == 123 || anInt == 999； }}登录后复制

在控制器中，如果使用@Valid注解触发验证：import org.springframework.web.bind.annotation.PostMapping；import org.springframework.web.bind.annotation.RequestBody；import org.springframework.web.bind.annotation.RestController；import javax.validation.Valid；@RestControllerpublic class MyController { @PostMapping(quot；/validatequot；) public String validateDto(@Valid @RequestBody Dto dto) { return quot；DTO 验证成功quot；； }}登录后复制

当请求体中anInt字段为null时，期望的结果只是触发@NotNull的验证失败，并返回相应的错误信息。但实际情况是，isIntCustomValid()方法同时被调用，并因anInt为null而引发异常，最终导致HV000090错误。解决方案：在@AssertTrue方法中增加空值检查

解决此问题的最直接和优雅的方法是，在@AssertTrue修饰的自定义验证方法内部，显式地对所依赖的字段进行空值检查。只有当字段非空时，才执行其核心的业务逻辑验证。如果字段为空，则直接返回true，表示在这种情况下（字段已由@NotNull处理），此自定义验证条件被视为通过。

后面的DTO如下：import lombok.Data；import javax.validation.constraints.AssertTrue；import javax.validation.constraints.NotNull；import java.util.Objects； // 导入Objects工具类@Datapublic class Dto { @NotNull(message = quot；anInt 不能为空quot；) private Integer anInt； @AssertTrue(message = quot；anInt 必须是123或999quot；) public boolean isIntCustomValid() { // 优先检查anInt是否为null if (Objects.nonNull(anInt)) { //只有当anInt不为null时，才执行具体的业务逻辑验证 return anInt == 123 || anInt == 999； } // 如果anInt为null，则此认为AssertTrue条件通过。 //因为anInt的null性已由@NotNull注解负责处理。 return true； }}登录后复制

工作原理：当anInt为null时，isIntCustomValid()方法被调用。Objects.nonNull(anInt)判定为false。方法直接返回true。这意味着anI中@AssertTrue的验证逻辑nt为null时不会触发异常，并且被认为是“通过”的。此时，@NotNull注解会捕获anInt为null的情况，并报告相应的验证错误。当anInt不为null时，Objects.nonNull(anInt)判定为true。方法继续执行anInt == 123 ||一个整数 == 999的逻辑，根据结果返回真或假。

通过这种方式，我们有效的转发@AssertTrue的执行逻辑“绑定”到一个Int非空的前提下，避免了因访问空引用而导致的HV000090错误，同时保持了验证的清晰性：@NotNull负责非空检查，@AssertTrue非空情况下的业务逻辑检查。替代方案与比较

原问题中提到尝试使用@GroupSequence和@Groups。虽然这确实是处理复杂验证顺序的一种标准且强大的机制，但对于本例这种简单的“如果字段组非空则执行自定义验证”的场景，它可能会过于复杂。

使用@GroupSequence的步骤通常包括：定义空接口作为验证（例如FirstValidationGroup.class，在@NotNull和@AssertTrue上分别指定不同的验证组。在DTO或方法参数上使用@GroupSequence指定验证组的执行顺序。

例如：public interface FirstValidation {}public interface SecondValidation {}@Data@GroupSequence({FirstValidation.class， SecondValidation.class， Dto.class}) // Dto.class代表默认组public class Dto { @NotNull(groups = FirstValidation.class) private Integer anInt； @AssertTrue(groups = SecondValidation.class) public boolean isIntCustomValid() { return anInt == 123 || anInt == 999； }}登录后复制方法确实能控制验证顺序，但引入了额外的这种接口和更复杂的配置。对于本例，为了避免一个NullPointerException，在@AssertTrue方法内部进行空值检查更为简洁和相应，因为将相关的逻辑封装在一起，减少了样板代码。只有当验证逻辑的依赖复杂程度非常高，或者需要根据不同的场景关系应用不同的验证规则集时，@GroupSequence才具有优势。注意事项防御性编程：在任何自定义验证方法中，如果该方法依赖于DTO的某个字段，始终建议进行空值检查，占用不必要的运行时错误。这是一种良好的编程实践。错误消息：确定@NotNull和@AssertTrue都提供了的错误消息，以便后续或调用方能够准确理解验证失败的原因。验证粒度： 这种方案将@AssertTrue的有效绑定到了其依赖字段的非空性上。如果业务需求是即使字段为null，@AssertTrue也应该表达某种“无效”状态，那么解决方案就重新使用验证逻辑，或者确实考虑使用@GroupSequence来强制分离验证阶段。但在大多数情况下，如果一个自定义验证依赖于字段的值，那么字段为null时，该自定义验证通常不会被视为失败，而是由@NotNull负责处理。在Spring中总结

Boot中使用Bean Validation时，@NotNull与@AssertTrue的组合验证顺序问题是常见痛点。通过在@AssertTrue修饰自定义的验证方法中添加简单的空值检查，我们可以很好地解决HV000090错误，确保验证逻辑在正确的前提下执行，同时避免引入复杂的验证组配置。这种简单的方法、，且高效易于理解和维护，是一个处理此类场景的推荐实践。

以上就是Spring Boot数据校验：优雅处理@NotNull与@AssertTrue的验证顺序冲突的详细内容，更多请关注乐哥常识网其他相关文章！