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，我认为该功能非常危险，必须仅按以下方式使用：
最佳选择是什么，或其他任何选择？
谢谢！
当前的想法似乎是“容忍”空值，也就是说，通常允许它们，尽管某些操作的容忍度较低，并且最终可能会抛出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）的建议是很好的方法。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句