当前的想法似乎是“容忍”空值，也就是说，一般允许它们，尽管某些操作的容忍度较低，并且最终可能会抛出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）的建议是很好的方法。
