要約はほとんどそれをすべて言います。 ImmutableList.createFromIterable()
の関連するコードスニペットは次のとおりです。
_ if (element == null) {
throw new NullPointerException("at index " + index);
}
_
私はこれに何度か遭遇しましたが、汎用ライブラリ関数がこの制限を課す必要がある理由がわかりません。
編集1:「汎用」で、95%のケースで満足しています。しかし、私はまだImmutableList.of()
への100回の呼び出しを書いたとは思わず、これに何度も噛まれました。たぶん、私は外れ値です。 :)
編集2:私の大きな不満は、標準の_Java.util
_コレクションとやり取りするときに「一時的な中断」が発生することだと思います。講演で指摘したように、コレクション内のnull
sの問題は、それらのnullが挿入された場所から遠く離れて現れる可能性があります。しかし、一方の端で標準コレクションにnullを配置し、もう一方の端でそれらを適切に処理するコードの長いチェーンがある場合、途中でgoogleコレクションクラスを置き換えることはできません。 NullPointerException
をスローします。
私はこのビデオの25分の時点でこれを説明しました: http://www.youtube.com/watch?v=ZeO_J2OcHYM
怠惰な答えで申し訳ありませんが、これは結局のところ「なぜ」の質問にすぎません(おそらくStackOverflowには適切ではありませんか?)。
編集:ビデオで明確にしたかどうかわからないもう1つのポイントは、合計(世界中のJava全体)です。 code)、古いスタンバイCollections.unmodifiableList(Arrays.asList(...))
などを使用するためにnullに適したケースのために記述しなければならない余分なコードの量は、(世界中のJava全体で、合計に圧倒されます。 code)私たちのコレクションがあなたのためにそれを処理しなかった場合に誰もが追加する必要がある余分なcheckArgument(!foos.contains(null))
呼び出しの量。ほとんどの場合、FARによると、コレクションの使用法ではnullが存在することは想定されておらず、nullが存在する場合は、実際にはすぐに失敗するはずです。
一般に、Googleコレクションでは、開発者はnullが予想される汎用パラメータであるべきだとは考えていないグループに属しています。
その理由の1つは、リストで機能する関数がすべての要素でNullをチェックする必要がなく、パフォーマンスが大幅に向上することです。