有没有真正的理由使用Opport.of()?

我在这里读到为什么应该过度使用,但答案根本没有让我满意,所以我问略有不同:Optional.of()Optional.ofNullable()

如果您确定您的方法不会返回,为什么要使用?据我所知,它或多或少的唯一目的是提醒“方法的用户”,他可能必须处理-值。如果他不必处理 -值,他为什么要为 ?nullOptionalnullnullOptional

我问,因为我最近让我的服务层返回可选而不是空值(在某些情况下)。我使用并非常困惑,当它抛出一个NullPointer。Optional.of()

我所做的示例:

Optional valueFromDB = getUserById("12");
User user = valueFromDB.get(); 

.....

public Optional<User> getUserById(String id) {
  //...
  return Optional.of(userRepository.findOne(id)); // NullPointerException!
}

如果null是不可能的,我不明白为什么人们会把它包装在.链接答案中的家伙说:“好吧,如果发生NullPointer,它会立即发生!但我真的想要这样吗?如果一个的唯一目的是,提醒程序员谁得到这样一个对象,记住(他必须解开它),我为什么要在包装时拥有呢?OptionalOptionalnullNullPointerException


编辑:我需要编辑问题,因为它被标记为重复,即使我已经从一开始就链接了所述问题。我也确实解释了为什么答案没有让我满意,但现在我需要编辑我的文本并解释。但这里有一些我想问的问题的附录,因为我得到了5个答案,每个人都回答了不同的情况,但没有一个完全涵盖了我在这里试图问的问题:

有没有一个原因,Optional.of(null)是不可能的,他们专门为null情况添加了Opport.ofNullable()?

使用流应该不是我对实现的想法的问题。我从您的回答中获得了很多见解,谢谢。但真正的问题直到现在才得到解答,据我所知/阅读/理解。也许我应该问:“如果我们删除该方法并且只允许在Java 9中,除了向后兼容性之外,还会有任何问题吗?Optional.of()Optional.ofNullable()


答案 1

您将 API 设计原理与特定实现代码中的知识混为一谈。方法完全有可能声明返回 一个 ,因为该值可能不存在,而在方法中的某个代码位置,已知它肯定存在。即Optional

String content;
public Optional<String> firstMatch(String pattern) {
    Matcher m = Pattern.compile(pattern).matcher(content);
    return m.find()? Optional.of(m.group()): Optional.empty();
}

此方法的返回类型表示可能不存在的 a,而在创建实例的代码位置,已知该值是存在还是不存在。这不是关于在这里检测值。StringOptionalnull

同样,在 Stream API 方法和 中,将一度知道是否存在匹配元素,而支持在匹配元素的情况下将其存在转换为不存在是显式不支持的,并且应该根据规范引发 。因此,将用于返回匹配元素,使用时可以在堆栈跟踪中轻松识别该元素findFirst()findAny()nullNullPointerExceptionOptional.ofStream.of((Object)null) .findAny();


答案 2

当您知道不能为 null 时,使用的另一个原因是,如果要对该 执行其他过滤操作。Optional.of(value)valueOptional

例如:

public static long getPageSizeFrom(HttpServletRequest request) {
    return Optional.of(request.getParameter("pageSize"))
                   .filter(StringUtils::isNumeric)
                   .map(Long::valueOf)
                   .filter(page::hasPageSize)
                   .orElse(page::getDefaultPageSize)
}

推荐