10

コレクション参照がnullであるかどうかわからない場合は、反復する前にnullをチェックする必要があることはよくあることです。サンプル：

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

もちろん、空のコレクションはnullよりもはるかに優れていることは知っていますが、場合によっては、クライアントコードが他のモジュールからのnull許容コレクションを制御できないことがあります（たとえば、サードパーティコードからの戻り値）。だから私はユーティリティメソッドを書きました：

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

クライアントコードでは、nullをチェックする必要はもうありません。

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

あなたnullableIterable()は合理的だと思いますか？何かアドバイス？何か心配はありますか？ありがとう！

4

3 に答える 3

6

よさそうだ。私も個人的にそうしています。これは一種の防御的なプログラミングであるため、これに同意しない開発者を常に獲得します。を返すことを想定していないワークフローまたはクラスがあるとし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!");
   //...
}
于 2012-07-07T08:41:20.577 に答える
0

この関数の使用を「外部」コードと相互作用するレイヤーに制限し、自分自身や同僚からの防御のためにこの関数の使用を開始しないようにすると、これは私には良さそうです。コード内のパラメーターとフィールドに@Nullableアノテーションを付けることを検討してください。アノテーションが付けられていないものをnullにできないと仮定すると、特にIDEと静的分析ツールがこのアノテーションを認識していることを考慮すると非常に役立ちます。

于 2012-07-07T09:10:02.020 に答える
0

ほとんどの場合、これで問題ありません。
エラーが発生した場合に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
}
于 2012-07-07T11:04:01.470 に答える