为什么 ImmutableList.of() 和类似的方法禁止 null 元素?

发布于 2024-08-21 16:53:50 字数 561 浏览 4 评论 0原文

摘要已经说明了一切。以下是 ImmutableList.createFromIterable() 中的相关代码片段:

  if (element == null) {
    throw new NullPointerException("at index " + index);
  }

我已经多次遇到过这种情况,但不明白为什么通用库函数应该施加此限制。

编辑 1:通过“通用”,我会对 95% 的情况感到满意。但我认为我还没有编写过 100 个对 ImmutableList.of() 的调用,并且不止一次被这个问题困扰。但也许我是个异类。 :)

编辑 2:我想我最大的抱怨是,在与标准 java.util 集合交互时,这会产生“打嗝”。正如您在演讲中指出的,集合中 null 的问题可能会在远离插入这些 null 的位置处出现。但是,如果我有一长串代码,将空值放入标准集合中,并在另一端正确处理它们,那么我无法在任何时候替换谷歌集合类,因为它会立即抛出 NullPointerException 。

Summary pretty much says it all. Here's the relevant snippet of code in 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. :)

Edit 2: I guess my big complaint is that this creates a "hiccup" when interacting with standard java.util collections. 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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

千秋岁 2024-08-28 16:53:50

一般来说,在 Google Collections 中,开发人员不认为 null 应该是预期的通用参数。

In general in Google Collections the developers are of the group that does not believe that nulls should be an expected general purpose parameter.

山色无中 2024-08-28 16:53:50

来自 Guava 的 Github 页面

不小心使用 null 可能会导致各种各样的错误。通过研究 Google 代码库,我们发现 95% 的集合中不应包含任何 null 值,让这些集合快速失败而不是默默地接受 null 会对开发人员有所帮助。

Guava 的立场主要是,还有其他方法可以避免集合中的 null 。例如,使用特定键获取一批项目。例如

// If a widget for the given id does not exist, return `null` in the list
private List<Widget> getWidgets(List<String> widgetIds);

// Could be restructured to use a Map type like this and avoids nulls completely.

// If a widget for the given id does not exist, no entry in list
private Map<String, Widget> getWidgets(List<String> widgetIds);

From Guava's Github Page

Careless use of null can cause a staggering variety of bugs. Studying the Google code base, we found that something like 95% of collections weren't supposed to have any null values in them, and having those fail fast rather than silently accept null would have been helpful to developers.

The Guava position is largely, that there are other ways to avoid nulls in collections. For example, fetching a batch of items with a specific key. E.g.

// If a widget for the given id does not exist, return `null` in the list
private List<Widget> getWidgets(List<String> widgetIds);

// Could be restructured to use a Map type like this and avoids nulls completely.

// If a widget for the given id does not exist, no entry in list
private Map<String, Widget> getWidgets(List<String> widgetIds);
2024-08-28 16:53:50

原因之一是它允许在列表上工作的函数不必检查每个元素是否为 Null,从而显着提高了性能。

One reason is that it allows functions that work on the list not to have to check every element for Null, significantly improving performance.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文