我们应该如何管理jdk8流中的空值

Question

Java开发人员大家好，

我知道这个主题可能有点，in advance因为JDK8尚未发布（无论如何现在还没有。），但是我正在阅读一些有关Lambda表达式的文章，尤其是与与称为Stream的新集合API相关的部分。

这是《Java杂志》文章中给出的示例（这是一种水獭种群算法。）：

Set<Otter> otters = getOtters();
System.out.println(otters.stream()
    .filter(o -> !o.isWild())
    .map(o -> o.getKeeper())
    .filter(k -> k.isFemale())
    .into(new ArrayList<>())
    .size());

我的问题是，如果在Set内部迭代的中间，水獭之一为null，会发生什么情况？

我希望抛出NullPointerException，但是也许我仍然停留在以前的开发范例（非功能性）中，有人可以启发我，因为应该如何处理？

如果确实抛出了NullPointerException，我认为该功能非常危险，必须仅按以下方式使用：

• 开发人员确保没有null值（也许使用以前的.filter（o-> o！= null））
• 开发人员确保应用程序永远不会生成空水獭或特殊的NullOtter对象来处理。

最佳选择是什么，或其他任何选择？

谢谢！

Answer 1

当前的想法似乎是“容忍”空值，也就是说，一般允许它们，尽管某些操作的容忍度较低，并且最终可能会抛出NPE。请参阅Lambda
Libraries专家组邮件列表中有关null的讨论，尤其是此消息。随后出现了关于选项3的共识（道格·利阿提出了明显反对）。因此，是的，OP对NPE炸毁管道的担忧是正确的。

托尼·霍尔将空值称为“十亿美元的错误”并非毫无道理。处理null是一个真正的痛苦。即使使用经典集合（不考虑lambda或流），也存在null问题。正如fge在评论中提到的那样，某些集合允许使用null，而另一些则不允许。对于允许空值的集合，这会在API中引入歧义。例如，对于Map.get（），返回null表示该键存在并且其值为null或该键不存在。必须做出额外的工作来消除这些情况的歧义。

null的通常用法是表示不存在值。针对Java SE
8提出的解决方案是引入一种新java.util.Optional类型，该类型封装了值的存在/不存在以及提供默认值，引发异常或调用函数等行为（如果有的话）该值不存在。Optional只能由新的API使用，但是，系统中的所有其他内容仍然不得不忍受null的可能性。

我的建议是尽可能避免实际的空引用。从给出的示例很难看出如何存在“空”水獭。但是，如果有必要，OP提出的过滤掉空值或将它们映射到哨兵对象（Null
Object Pattern
）的建议是很好的方法。