何时或在什么情况下我应该使用 Optional 来检查 null

Question

我应该总是使用 Optional 在 Java 8 中检查 null 吗？

在我的 DAO 层中使用它是一种好的做法吗？这是我的 DAO 层的片段代码：

public Optional<Tag> retrieveTagByValue(String tagValue) {
    Tag tag = null;
    try {
        tag = em.createNamedQuery("Tag.findByValue", Tag.class)
                .setParameter("tagValue", tagValue)
                .getSingleResult();
    } catch (NoResultException e) {
        System.out.println(e.getMessage());
    }
    return Optional.ofNullable(tag);
}

因为在我的服务层中，我想知道标签是否为空，如果为空，那么我创建一个新标签。所以我想知道在这种情况下我应该使用 Optional 吗，有没有更好的方法来改进这种方法？多谢！

Answer 1

无论您如何执行后续null检查，我都会称您的示例为不必要地引入null的反模式。

考虑：

public Optional<Tag> retrieveTagByValue(String tagValue) {
    try {
        Tag tag = em.createNamedQuery("Tag.findByValue", Tag.class)
                .setParameter("tagValue", tagValue)
                .getSingleResult();
        return Optional.of(tag);
    } catch (NoResultException e) {
        System.out.println(e.getMessage());
        return Optional.empty();
    }
}

这样，我们就不会使用Optional来执行null检查，而是使用它来首先不引入null。

与

捕获有意义的异常相比，对于调用方来说，在错误的情况下获得空Optional并且必须循环并解析标准输出以找出实际原因，这是否是一种改进仍然值得商榷。

但是，如果没有结果被认为是在此方法的正常运行范围内(与Stream.findAny()相比(，则返回空Optional就可以了，但是，没有必要打印消息以System.out。

Answer 2

我应该在 Java 8 中始终使用 Optional 来检查 null 吗？

如果一个方法在 Java 7 及更低版本中返回 null，那么你应该在 Java 8 中使用Optional.empty()。使用 Optional 可以帮助您摆脱null检查，并使代码更易于阅读。 Optional虽然在流中使用。

我将按以下方式重写代码：

public Optional<Tag> retrieveTagByValue(String tagValue) {
    try {
        Tag tag = em.createNamedQuery("Tag.findByValue", Tag.class)
            .setParameter("tagValue", tagValue)
            .getSingleResult();       
        return Optional.of(tag);
    } catch (NoResultException e) {
        return Optional.empty();
    }
}

使用 System.out... 进行日志记录不被认为是一种好的做法，您应该改用一些日志记录库。

在我的 DAO 层中使用它是一种好的做法吗？

就个人而言，我会用存储库替换 DAO(查看 Spring 数据(，我会在服务层中使用Optional。

Answer 3

我想知道标签是否为空

而不是这是使用可选的完美情况。你得到了关于如何重构代码的解释，但请考虑此方法的调用者。

您非常明确地表示，此方法可能会返回不存在的结果 - 通过Optional.empty表示，或者可能存在的结果，通过Optional.get/isPresent等表示。通过这种方式，您可以强制调用方根据结果是否存在做出一些决定。返回引用时根本不是这种情况。