Question

当不确定集合引用是否为null时，我必须在迭代之前检查null是很常见的。样品：

Collection<Object> collection = ...
...
if(collection != null)//troublesome
    for(Object o : collection)

当然，我知道空集合比null要好得多，但在某些情况下，客户端代码无法控制来自其他模块的可空集合（例如，从第三方代码返回值）。所以我写了一个实用方法：

public static <T> Iterable<T> nullableIterable(Iterable<T> it){
    return it != null ? it : Collections.<T>emptySet();
}

在客户端代码中，不再需要检查null：

for(Object o : nullableIterable(collection))
...

您认为nullableIterable()是否合理？有什么建议？有顾虑吗？谢谢！

Answer 1

看起来不错。我个人也这样做。你将永远得到那些不同意这一点的开发者，因为它是一种防御性编程。想象一下，你有一个工作流程或一个不应该返回null的类。这意味着从中获取null是您的代码隐藏的错误，因为它会将null转换为空集合，并且该错误永远不会浮出水面。

如果您要编写不支持null集合的API，那么您应该避免这种情况。如果客户端代码为您提供了不支持它的null集合，则应抛出IllegalArgumentException以让客户端代码知道提供的集合有问题。类似的东西：

public void myApiNoSupportForNull(Collection<Object> collection){
   // Pre condition
   if(collection == null) 
     throw new IllegalArgumentException("This API does not support null collections!");
   //...
}

Answer 2

如果您将此功能的使用限制在与“外部”代码交互的图层上，并且确保您永远不会开始使用它来保护您自己或同事的防御，那么这对我来说很好。考虑使用@Nullable注释在代码中注释参数和字段 - 假设没有注释的内容不能为null，非常有用，特别是考虑到IDE和静态分析工具都知道这个注释。

Answer 3

在大多数情况下，这没关系。
请记住，如果出现错误，您可能会遇到返回null的第三方，并且空列表是有效结果。
因此，我会考虑改变你的代码并执行类似的操作：

public static <T> Iterable<T> nullableIterable(Iterable<T> it, boolean exceptionIfNull){
    if (exceptionIfNull && it == null) {
        throw new NUllPointerException("Iterable is null");
    } else
    return it != null ? it : Collections.<T>emptySet();
}

public static <T> Iterable<T> nullableIterable(Iterable<T> it){
    return nul,lableIterable(it,false); //Default behavior for most cases
}

Iterator null集合

3 个答案: