可以在较大的表达式中使用可选的ifPresent()来缓解对get()的调用吗？

Question

为了避免调用get()哪个可以抛出异常:

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

我可以用以下代码替换此表达式

a.ifPresent(list::add);

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

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

是否仍然可以使用lambda表单来缓解对此的调用get()？

我的用例是尽可能避免get()在可能的情况下避免错过可能未经检查的异常.

Answer 1

我的假设是你必须分别对待其他人boolean,但我可能是错的.

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

实际上,一个奇怪的解决方案可能是:

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

注意

@Zhro有些人希望尽可能使用功能,无论是否有意义都无关紧要. (11认同)
太多这个,它看起来像线路噪音,即使你知道它做了什么 (3认同)
@Zhro,如果谓词很昂贵,那么`filter(...)`选项会更好,因为它们不会被调用为空的可选项. (3认同)
@nullpointer:这就像`if(b)a.filter(o - > c).ifPresent(list :: add);`一样简单,但你不应该为它们的副作用评估布尔表达式.如果`b`是一个可以求值为可选的表达式,你也可以使用`optionalCreateByB.flatMap(o - > a).filter(o - > c).ifPresent(list :: add);`... (3认同)
`filter(o - > b && c)`呃我不同意......为什么应用过滤器,如果它与你要过滤的对象无关.永远不会通过任何理智的人的代码审查 (2认同)
...除此之外我会考虑短路条件,这个代码会检查`b`,尽管`a.isPresent()`是'false`这一事实. (2认同)
***什么***？!如果可选项为空,则传递给"filter"的谓词不会被**评估. (2认同)
@nullpointer:在`filter`的情况下,它没有.应该如何为不存在的对象评估谓词？传递'null`？这正是可选项应该阻止的内容.因此,如果可选项为空,则它不会*评估`filter`谓词. (2认同)

Answer 2

在以前的答案中添加一个变体:

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

如果a存在.检查然后添加未包装的对象