时间戳

首页 > 解决方案 > 如何确定Java集合是否包含`null`

java - 如何确定Java集合是否包含`null`

问题描述

我想编写一个将集合作为参数的方法。但是，该集合不能包含null. 如果它包含null，这将在稍后导致 NullPointerException ，此时不再清楚null来自哪里。因此，我想验证输入。天真的方法是：

public void doSomething(Collection<?> collection) {
    if (collection.contains(null))
        throw new IllegalArgumentException("collection cannot contain null!");

    // do something
}

但是，Collection.contains如果集合不支持null值，则可能会抛出 NullPointerException。事实上，Java 自己的不可变集合就是这样做的。因此，在幼稚的方法中，以下代码不起作用：

doSomething(List.of("a", "b", "c")); // NullPointerException!

有一些可能的解决方案，但没有一个感觉是对的。

例如，我可以搜索null自己：

public void doSomething(Collection<?> collection) {
    for (var e : collection) {
        if (e == null)
            throw new IllegalArgumentException("collection cannot contain null!");
    }
    // do something
}

但现在我正在进行线性搜索，尽管集合可能是 HashSet 或 TreeSet，但提供了更好的性能。

或者我可以捕获 NullPointerException：

public void doSomething(Collection<?> collection) {
    try {
        if (collection.contains(null))
            throw new IllegalArgumentException("collection cannot contain null!");
    } catch (NullPointerException e) {
        // Apparently, collection doesn't support null. This is good!
    }
    // do something
}

但这感觉很不安全。我真的可以确定 NullPointerException 是由不支持空值的集合引起的，还是我只是吃了一个可以提供有关错误的有价值信息的异常？

有没有确定集合是否包含的好方法null？

标签： javacollections

解决方案

我不认为，用NullPointerExceptionan替换 aIllegalArgumentException是一种改进。它要求我们阅读一条消息以获取专用异常类型本质上告诉我们的信息。

当然，尽早检查传入的参数，避免将问题的根源与异常发生的地方分开，是一件好事。当我使用时，例如

public static void main(String[] args) {
    new NullCheckExample().doSomething(Arrays.asList("foo", "bar", null));
}

public void doSomething(Collection<?> collection) {
    collection.forEach(Objects::requireNonNull);

    // do something
}

我明白了

Exception in thread "main" java.lang.NullPointerException
    at java.base/java.util.Objects.requireNonNull(Objects.java:208)
    at java.base/java.util.Arrays$ArrayList.forEach(Arrays.java:4204)
    at NullCheckExample.doSomething(NullCheckExample.java:12)
    at NullCheckExample.main(NullCheckExample.java:8)

我认为它足够有表现力，有助于追查原因。

null现在，有没有办法在不可能的情况下避免线性搜索的成本？理论上，是的。我们可以做的

public void doSomething(Collection<?> collection) {
    Spliterator<?> sp = collection.spliterator();
    if(sp.hasCharacteristics(Spliterator.NONNULL)) {
        // yeah, null is impossible
    }
    else if(sp.hasCharacteristics(Spliterator.SORTED) && sp.getComparator() == null) {
        // natural order precludes null too
    }
    else {
        // here we have to check,
        // collection.forEach(Objects::requireNonNull)
        // or 
        // if(collection.contains(null)) throw ...
    }

    // do something
}

这确实适用于某些集合，例如并发集合或TreeSet. 问题是，它不适用于List.of(…)或Set.of(…)某种收藏。在参考实现（OpenJDK）中，该spliterator 方法没有被覆盖，这不仅意味着 Stream 操作效率较低，我们也没有得到NONNULL也不IMMUTABLE特性。

所以在这些情况下，我们最终会进行不必要的线性搜索，或者必须处理contains(null)抛出 a NullPointerException（在常见情况下，而不是错误情况下）。

根据你想做的事情，你可能会做类似的事情

public void doSomething(Collection<?> collection) {
    List<?> workingCopy = List.copyOf(collection);

    // do something
}

这具有复制操作，但确实可以保护您免受后续修改集合的影响，无论如何都可能需要这样做，以确保一致性。工作副本保证免费null且不会更改。如果调用者将结果传递给List.of(…)该方法，该方法已经满足条件，copyOf则将变为无操作，只返回参数。因此，当您期望输入在大多数情况下已经是不可变列表时，这是最佳选择。

但是，如果您要说这两者都不是令人满意的解决方案，我会同意。应该有有效的可能性来排除null. 拒绝查询尝试null是可以的，但不应最终导致无法有效地确保没有null. 令人困惑的是，不可变集合既没有有效的实现spliterator()也没有forEach实现，尽管在大多数情况下它们的实现非常简单，单行。

推荐阅读