Java，在返回和使用“null”时比 Optional 更好吗？ [关闭]答案

【问题标题】：Java, when returning and using "null" better than Optional? [closed]Java，在返回和使用“null”时比 Optional 更好吗？ [关闭]
【发布时间】：2020-05-24 04:14:06
【问题描述】：

我是java新手，以前用过php、python和js。最近是 python，所以要习惯像“如果 myVar 是 None:”这样的东西。这是我的问题：我从某个库中获取语言环境作为可选，我只需要返回一种语言，或者如果发生超时或一些错误等，则需要返回其他内容。然后我需要将语言传递给某个对象（上下文），并且稍后将上下文转换为请求的参数。所以我做了类似的事情

String getLanguage(){
  try {
    Optional<String> locale = getLocale();
    if (locale.isPresent()){logging, locale.get()-to-language conversion, language validation, 
      logging, return language} 
    else (logging, return null;)
  } except {logging error, return null};
}

Context c = new Context();
c.setSomething(something);
c.setLanguage(getLanguage());

and somewhere later:
Request r = new Request();
r.addParam(something, c.getSomething());
if (c.getLanguage() != null) {r.addParam(language, c.getLanguage())

我有一个使用 Optional 重写所有内容的建议。用类似的方法替换我的第一个方法。

Optional<String> getLanguage(){
  try {
    Optional<String> locale = getLocale();
    return locale.ifPresent(logging)
          .map(locale-to-language conversion, language validation, logging, return language}
          .orElse(logging, return Optional.isEmpty())
  } except {logging error, return Optional.isEmpty()};
}

and then somewhere later c.getLanguage().ifPresent(x -> r.addParam(language, x))

我以前从未使用过 Optional，所以我很高兴能学到一些新东西，我假设对于习惯了 Optional 的人来说，我的代码并不好。从另一面，我看到这里的 Optional 在这里有点矫枉过正——我需要修改我的数据类 Context 来处理 Optional，我的 map() 和 orElse() 很难看——它们有 2-5 行代码，等等。还有单元测试需要返工。所以，我的问题是 - 对 Optional 的这些更改是否会增加一些好处，或者我们只是在不假思索地追随时尚。

【问题讨论】：

在特定环境中使用您认为最适合阅读的内容。
...除此之外，只需尝试将 map(locale-to-language conversion, language validation, logging, return language} 之类的内容移动到它们自己的方法中。
这段代码甚至无法编译。请先提供一个最小且可重现的示例：stackoverflow.com/help/minimal-reproducible-example
@Naman，已经做到了。那些“语言环境到语言的转换”和“语言验证”已经是方法，而且我的日志记录正在使用其他一些局部变量，所以如果我将这些东西转移到新方法中，我需要 3 个额外的参数来进行日志记录。方法看起来不太好。
@RavindraRanwala 这是代表想法的伪代码，不是真实代码。

标签： java optional

【解决方案1】：

所以，我的问题是 - 对 Optional 的这些更改是否会增加一些好处...

这两种方法肯定各有利弊：

从Optional 方面看，主要的“加号”是您消除了主要的错误来源；即 NPE 是由于未正确处理可能返回的 null 而引起的。主要的“缺点”是使用Optional 的代码冗长，而且它实际上并没有消除所有错误；例如如果您在“空”Optional 上调用 Optional.get，您将收到异常。

其他问答更详细：

...或者我们只是在不假思索地追随时尚。

这是一个不同的问题！

现在我想有些人可能会不假思索地使用Optional，但我没有看到太多证据。很明显，有优点和缺点，需要思考。

所以你真的应该问（你自己！）如果>>你

我有一个建议[在我的示例中] 使用Optional 重写所有内容。

这是我的建议。

在您的版本控制系统中创建一个分支。
在分支中，将您的 API 方法更改为使用 Optional，并更改代码中使用 API 方法的所有位置。
做出判断：这是否有所改善？这些努力值得吗？
如果 API 当前或将要被其他人的代码使用，也请询问他们的意见。
决定是否继续，执行决定，然后继续下一个问题。

如果这听起来工作量太大，另一种选择是悄悄地忽略该建议。

无论哪种方式，我们（StackOverflow 社区）都无法为您做出决定。我们没有上下文¹，即使有，也会有各种各样的意见，也没有明确的正确答案。

^{1 - 例如，没有区域设置和可确定语言的可能性有多大。整个应用程序应该怎么做？它应该出手吗？它应该替代默认值吗？可以在这里替换默认值吗？我们看不到“大局”。}

【讨论】：

虽然总的来说这是一个很好的答案，但我不同意the main "plus" is that you eliminate a major source of bugs; i.e. NPE's 如果你没有正确检查Optional，它会抛出NoSuchElementException。这不是对 NPE 的改进。我自己称其为“假功能”。
已更新。更好？
我认为您的解释很清楚，但我不确定是不是这个原因。这个想法类似于如果你将返回的null 传递给另一个方法或类，并且 that 类抛出 NPE，NPE 实际上并不指向导致问题的代码。 Optional 应该通过强制接收器进行测试来改变这一点。但我仍然觉得这没有足够的价值来让额外的复杂性变得值得。
见仁见智。我不会以一种或另一种方式对意见作出判断。如果您认为这很重要，那么您应该编写自己的答案。

【解决方案2】：

当您的代码知道如何处理 null 情况时，我会说 Optional 很好。比如你可以写

 public String helloWorld(Optional<Long> input){
     String toReturn = "Hello "+ input.orElse("0")+ " times";
     return toReturn;
 }

但是，如果您正在与遗留代码交互并且这些函数需要空输入，这会迫使您编写类似

if(someOptional.isPresent()){
       return somevalue;
} else{
       return null;
 }

在上述情况下，Optional 并没有给你带来更多，只是使用 null。在这种情况下，我会使用 null 而不是 Optional。

【讨论】：