跳到主要内容

仓库方法的空值处理

Doubao 中英对照 Null Handling of Repository Methods

返回单个聚合实例的仓库 CRUD 方法可以使用 Optional 来指示值可能不存在。除此之外,Spring Data 还支持在查询方法上返回以下包装器类型:

  • com.google.common.base.Optional

  • scala.Option

  • io.vavr.control.Option

或者,查询方法也可以选择完全不使用包装器类型。在这种情况下,查询结果不存在将通过返回 null 来表示。返回集合、集合替代类型、包装器和流的仓库方法保证永远不会返回 null,而是返回相应的空表示。有关详细信息,请参阅“仓库查询返回类型”。

可空性注解​

JSpecify​

自 Spring Framework 7 和 Spring Data 4 起,您可以使用 JSpecify 为仓库方法表达可空性约束。JSpecify 已与 IntelliJ 和 Eclipse 良好集成,提供了一种对工具友好的方式,并在运行时按需启用 null 检查,如下所示:

  • @NullMarked:用于模块级、包级和类级,以声明参数和返回值的默认行为分别为既不接受也不产生 null 值。

  • @NonNull:在类型级别用于不得为 null 的参数或返回值(在已被 @NullMarked 覆盖的参数和返回值上无需使用)。

  • @Nullable:在类型级别用于可以为 null 的参数或返回值。

  • @NullUnmarked:用于包级、类级和方法级,以回滚空性声明,并从先前的 @NullMarked 中退出。在这种情况下,空性变为未指定。

@NullMarked
package org.springframework.core;

import org.jspecify.annotations.NullMarked;
java

在属于该包的各个 Java 文件中,可空类型的使用通过 @Nullable 显式定义。建议将该注解紧挨着相关类型之前指定。

例如,对于某个字段:

private @Nullable String fileEncoding;
java

或者,对于方法参数和返回值:

public static @Nullable String buildMessage(@Nullable String message,
@Nullable Throwable cause) {
// ...
}
java

重写方法时,空性注解不会从超类方法继承。这意味着,如果您只想重写实现并保持相同的 API 空性,就应当重复这些空性注解。

对于数组和可变参数,您需要能够将元素的空性与数组本身的空性区分开来。请注意 Java 规范所定义的语法,它起初可能会让您感到意外:

  • @Nullable Object[] array 表示各个元素可以为 null,但数组本身不可以。

  • Object @Nullable [] array 表示各个元素不可以为 null,但数组本身可以。

  • @Nullable Object @Nullable [] array 表示各个元素和数组本身都可以为 null。

Java 规范还强制要求:对于像 JSpecify 的 @Nullable 这样以 @Target(ElementType.TYPE_USE) 定义的注解,在使用内部类型或全限定类型时,应将其指定在最后一个 . 之后:

  • Cache.@Nullable ValueWrapper

  • jakarta.validation.@Nullable Validator

对于典型用例,@NonNull 和 @NullUnmarked 应该很少被用到。

Spring Framework 可空性与 JSR-305 注解​

您可以使用 Spring Framework 的可空性注解 为仓库方法表达可空性约束。

备注

自 Spring Framework 7 起,Spring 的可空性注解已被废弃,转而推荐使用 JSpecify。有关更多信息,请参阅框架文档中关于从 Spring 空安全注解迁移到 JSpecify 的内容。

它们提供了一种对工具友好的方式,并在运行时按需启用 null 检查,如下所示:

  • @NonNullApi:用于包级,以声明参数和返回值的默认行为分别为既不接受也不产生 null 值。

  • @NonNull:用于不得为 null 的参数或返回值(在适用 @NonNullApi 的参数和返回值上无需使用)。

  • @Nullable:用于可以为 null 的参数或返回值。

Spring 注解使用 JSR 305 注解(一个已休眠但被广泛使用的 JSR)进行元注解。JSR 305 元注解让工具厂商(例如 IDEA、Eclipse 和 Kotlin)能够以通用方式提供空安全支持,而无需为 Spring 注解硬编码支持。要启用对查询方法可空性约束的运行时检查,您需要在 package-info.java 中使用 Spring 的 @NonNullApi 在包级启用非空性,如下例所示:

一旦非空默认设置到位,仓库查询方法的调用就会在运行时针对可空性约束进行校验。如果查询结果违反了所定义的约束,就会抛出异常。当方法本应返回 null 却被声明为不可空时(这是在仓库所在包上定义该注解后的默认行为),就会发生这种情况。如果您想重新选择可空的结果,可以在个别方法上有选择地使用 @Nullable。使用本节开头提到的结果包装器类型仍会按预期工作:空结果会被转换为表示“不存在”的值。

以下示例展示了刚才描述的若干技巧:

package com.acme;                                                       1

import org.springframework.lang.Nullable;

interface UserRepository extends Repository<User, Long> {

User getByEmailAddress(EmailAddress emailAddress); 2

@Nullable
User findByEmailAddress(@Nullable EmailAddress emailAddress); 3

Optional<User> findOptionalByEmailAddress(EmailAddress emailAddress); 4
}
java
  • 该仓库位于我们已为其定义了非空行为的包(或子包)中。

  • 当查询未产生结果时抛出 EmptyResultDataAccessException。当传给方法的 emailAddress 为 null 时抛出 IllegalArgumentException。

  • 当查询未产生结果时返回 null。同时接受 null 作为 emailAddress 的值。

  • 当查询未产生结果时返回 Optional.empty()。当传给方法的 emailAddress 为 null 时抛出 IllegalArgumentException。

基于 Kotlin 的仓库中的可空性​

Kotlin 将可空性约束的定义内置于语言之中。Kotlin 代码编译为字节码,字节码并不通过方法签名而是通过编译期内置的元数据来表达可空性约束。请确保在您的项目中包含 kotlin-reflect JAR,以启用对 Kotlin 可空性约束的内省。Spring Data 仓库使用该语言机制来定义这些约束,以应用相同的运行时检查,如下所示:

interface UserRepository : Repository<User, String> {

fun findByUsername(username: String): User 1

fun findByFirstname(firstname: String?): User? 2
}
kotlin
  • 该方法将参数和结果都定义为不可空(Kotlin 的默认行为)。Kotlin 编译器会拒绝向该方法传递 null 的方法调用。如果查询产生空结果,则抛出 EmptyResultDataAccessException。

  • 该方法的 firstname 参数接受 null,并且当查询未产生结果时返回 null。