Java开发人员大家好,
我知道这个主题可能有点,in advance因为JDK8尚未发布(无论如何现在还没有。),但是我正在阅读一些有关Lambda表达式的文章,尤其是与与称为Stream的新集合API相关的部分。
in advance
这是《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的可能性。
java.util.Optional
Optional
我的建议是尽可能避免实际的空引用。从给出的示例很难看出如何存在“空”水獭。但是,如果有必要,OP提出的过滤掉空值或将它们映射到哨兵对象(Null Object Pattern)的建议是很好的方法。