跳到主要内容

仓库方法的空值处理

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 规范还规定，使用 @Target(ElementType.TYPE_USE) 定义的注解（如 JSpecify 的 @Nullable）在与内部类型或全限定类型一起使用时，应指定在最后一个 . 之后：

  • 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 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。