java 为什么 ImmutableList.of() 和朋友禁止空元素？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2252261/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why do ImmutableList.of() and friends prohibit null elements?
提问by Matt McHenry
Summary pretty much says it all. Here's the relevant snippet of code in ImmutableList.createFromIterable():
总结几乎说明了一切。这是 中的相关代码片段ImmutableList.createFromIterable()：
if (element == null) {
throw new NullPointerException("at index " + index);
}
I've run into this several times and can't see why a general-purpose library function should impose this limitation.
我已经多次遇到这种情况，但不明白为什么通用库函数应该强加这种限制。
Edit 1: by "general-purpose", I'd be happy with 95% of cases. But I don't think I've written 100 calls to ImmutableList.of()yet, and have been bitten by this more than once. Maybe I'm an outlier, though. :)
编辑 1：通过“通用”，我对 95% 的情况感到满意。但我认为我还没有写过 100 个电话ImmutableList.of()，并且不止一次被这个问题所困扰。不过，也许我是个局外人。:)
Edit 2: I guess my big complaint is that this creates a "hiccup" when interacting with standard java.utilcollections. As you pointed out in your talk, problems with nulls in collections can show up far away from where those nulls were inserted. But if I have a long chain of code that puts nulls in a standard collection at one end and handles them properly at the other, then I'm unable to substitute a google collections class at any point along the way, because it'll immediately throw a NullPointerException.
编辑 2：我想我最大的抱怨是这在与标准java.util集合交互时会产生“打嗝” 。正如您在演讲中指出的那样，null集合中 s 的问题可能会出现在远离插入这些空值的位置的地方。但是，如果我有一长串代码在一端将空值放入标准集合中并在另一端正确处理它们，那么我无法在此过程中的任何时候替换 google 集合类，因为它会立即扔一个NullPointerException。
采纳答案by Kevin Bourrillion
I explained this at the 25-minute point of this video: http://www.youtube.com/watch?v=ZeO_J2OcHYM
我在这个视频的 25 分钟时解释了这一点：http: //www.youtube.com/watch?v=ZeO_J2OcHYM
Sorry for the lazy answer, but this is after all only a "why" question (arguably not appropriate to StackOverflow?).
抱歉我的回答很懒，但这毕竟只是一个“为什么”的问题（可以说不适合 StackOverflow？）。
EDIT:Here's another point I'm not sure I made clear in the video: the total (across all of the world's Java code), amount of extra code that has to be written for those null-friendly cases to use the old standbys Collections.unmodifiableList(Arrays.asList(...))etc. is overwhelmed by the total (across all of the world's Java code) amount of extra checkArgument(!foos.contains(null))calls everyone would need to add if our collections didn't take care of that for you. Most, by FAR, usages of a collection do not expect any nulls to be present, and really should fail fast if any are.
编辑：还有一点我不确定我在视频中说清楚了：总数（在世界上所有的 Java 代码中），必须为那些对空友好的情况编写的额外代码量，以使用旧的备用数据库Collections.unmodifiableList(Arrays.asList(...))等checkArgument(!foos.contains(null))如果我们的集合没有为您处理这些，那么每个人都需要添加的额外调用总数（在世界上所有的 Java 代码中）让 . 不堪重负。大多数情况下，通过 FAR，集合的使用不希望出现任何空值，如果有的话，真的应该很快失败。
回答by Yishai
In general in Google Collections the developers are of the group that does not believe that nulls should be an expected general purpose parameter.
通常，在 Google Collections 中，开发人员属于不相信 null 应该是预期的通用参数的群体。
回答by 0xfe
One reason is that it allows functions that work on the list not to have to check every element for Null, significantly improving performance.
一个原因是它允许在列表上工作的函数不必检查每个元素是否为 Null，从而显着提高了性能。
