Java，当返回并使用“null”时比可选更好？[闭门]

Question

我是java新手，以前使用过php、python和js。最近使用python，所以要习惯类似“IfMyVar为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<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))

我以前从未使用过可选，所以我很高兴学习新的东西，我认为对于习惯可选的人来说，我的代码不好。从另一方面，我看到这里的可选性在这里是大材小用的——我需要修改我的数据类上下文来处理可选性，我的map（）和orElse（）是丑陋的——它们有2-5行代码，等等。单元测试也需要返工。所以，我的问题是——这些对可选的改变是增加了一些好处，还是我们只是不假思索地追随时尚。

Answer 1

当代码知道如何处理空情况时，我会说可选是好的。比如你可以写

 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。

Answer 2

所以，我的问题是-这些对可选的更改是否增加了一些好处。。。

这两种方法肯定都有优点和缺点：

从可选方面看，主要的“优点”是消除了bug的主要来源；i、 e.未正确处理可能返回的null而导致的NPE。主要的“缺点”是使用可选的代码冗长，而且实际上并没有消除所有bug；e、 g.如果您调用可选。在“空的”选项上获取，您将获得异常。

其他Q

• 空检查vs可选是当前检查
• 用于可选
• 可选vs. null。Java8中可选的目的是什么？
• 使用Optional.ofNullable作为三元运算符的替代是一个好的实践吗？

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

那是另一个问题！

现在我想有些人可能会不假思索地使用可选的，但我看不到多少证据。很明显，有优点也有缺点，这是需要思考的。

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

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

这是我的建议。

1. 在版本控制系统中创建分支
2. 在分支中，将API方法更改为使用可选，并更改代码中使用API方法的所有位置
3. 做出判断：这是否改善了情况？这样的努力值得吗
4. 如果API目前或将被其他人的代码使用，也要征求他们的意见
5. 决定是否继续，执行决定，然后继续下一个问题

如果这听起来像是太多的工作，另一个选择是静静地忽略这个建议。

无论哪种方式，我们（StackOverflow社区）都无法为您做出决定。我们没有上下文1，即使我们有，也会有一系列的观点，没有明确的正确答案。

^{1-例如，没有语言环境和可确定语言的可能性是多少。应用程序作为一个整体应该对此做些什么？它应该跳伞吗？它应该取代违约吗？可以在这里替换默认值吗？我们看不到“大局”。}