是否可以在更大的表达式中使用 Optional ifPresent() 来减轻对 get() 的调用？答案

【问题标题】：Can Optional ifPresent() be used in a larger expression to mitigate a call to get()?是否可以在更大的表达式中使用 Optional ifPresent() 来减轻对 get() 的调用？
【发布时间】：2017-10-17 04:55:44
【问题描述】：

为避免调用可能引发异常的get()：

if (a.isPresent())
   list.add(a.get());

我可以将这个表达式替换为：

a.ifPresent(list::add);

但是如果我需要执行更大的表达式，例如：

if (a.isPresent() && b && c)
   list.add(a.get());

是否仍然可以为此使用 lambda 形式来减轻对 get() 的调用？

我的用例是在可能的情况下完全避免get()，以防止错过可能的未经检查的异常。

【问题讨论】：

我相信another answer 在短路方面执行的顺序与问题的顺序完全相同，而不是目前接受的顺序......并且短路确实会影响执行多个布尔运算时的处理。
我们可以更新问题以包含if (b && a.isPresent() && c) list.add(a.get()); 以使其更有趣吗？

标签： java lambda java-8 optional

【解决方案1】：

我的假设是您必须分别对待其他 booleans，但我可能错了。

if (b && c) {
    a.ifPresent(list::add);
}

实际上，一种奇怪的解决方案可能是：

a.filter(o -> b && c).ifPresent(list::add);

注意

请务必查看 shinjw 的解决方案 here 以获取第三个示例！

【讨论】：

@Zhro 有些人总是希望尽可能使用函数式，不管它是否有意义。
这个太多了，看起来就像是线路噪音，即使你知道它的作用
filter(o -> b && c) ehh 我不同意...如果它与您要过滤的对象无关，为什么还要应用过滤器。永远不会通过任何理智的人的代码审查
@Zhro，如果谓词很昂贵，那么 filter(...) 选项会更可取，因为它们不会被空选项调用。
@nullpointer：这就像if(b) a.filter(o -> c).ifPresent(list::add); 一样简单，但无论如何你都不应该评估布尔表达式的副作用。如果b 是一个可以计算为可选的表达式，您也可以使用optionalCreateByB.flatMap(o -> a).filter(o -> c) .ifPresent(list::add);...

【解决方案2】：

在上一个答案的基础上再添加一个：

a.ifPresent(obj -> { if (b && c) list.add(obj); });

如果存在 a。检查然后添加展开的对象

【讨论】：

我想象他正在寻找使用方法参考 (lamda form?) 而不是写出 lamda。但我绝对认为这可能是最佳方法......考虑到如果可选为空，则不会执行额外的检查。
投票赞成，因为这是一个很好的答案，但在我的用例中，我希望简洁明了，因为短路和顺序并不重要，如前所述。雅各布还在他的末尾添加了一个指向此答案的链接。
我还想指出，这个答案解决了表达式必须按升序计算的问题（a -> b -> c）。