Any（）がnull参照例外をスローしないことを期待するのは理不尽ですか？

拡張メソッドを作成する場合、もちろん、それを呼び出すことができnullます。ただし、インスタンスメソッドの呼び出しとは異なり、nullで呼び出す場合、aをスローする必要はありませんNullReferenceException->手動でチェックしてスローする必要があります。

Linq拡張メソッドの実装について、Any()MicrosoftはArgumentNullException（https://github.com/dotnet/corefx/blob/master/src/System.Linq/src/System/Linq/AnyAll.cs）をスローすることを決定しました。

書かなければならないのはイライラする if( myCollection != null && myCollection.Any() )

このコードのクライアントとして、例えば((int[])null).Any()戻るべきだと期待するのは間違っていますfalseか？

5個のジャガイモが入った袋があります。.Any()袋にジャガイモは入っていますか？

「はい」とあなたは言います。<= true

私はすべてのジャガイモを取り出して食べます。.Any()袋にジャガイモは入っていますか？

「いいえ」とあなたは言います。<= false

私はバッグを火で完全に焼却します。.Any()袋にジャガイモが入っていますか？

「バッグはありません。」<= ArgumentNullException

まず、ソースコードはArgumentNullExceptionでなくをスローするようNullReferenceExceptionです。

とはいえ、多くの場合、このコードはコレクションが既に存在することを知っているコードからのみ呼び出されるため、コレクションがnullではないことをすでに知っているので、nullチェックを頻繁に入れる必要はありません。しかし、それが存在することを知らない場合は、呼び出す前に確認するのが理にかなってAny()います。

このコードのクライアントとして、例えば((int[])null).Any()戻るべきだと期待するのは間違っていますfalseか？

はい。質問Any()の答えは、「このコレクションは、すべての要素が含まれているのですか？」され このコレクションが存在しない場合、質問自体は無意味です。存在しないので、何も含むことも含まないこともできません。

Nullは、要素ではなく情報の欠落を意味します。

nullをより広く回避することを検討することもできます。たとえば、nullの代わりに、組み込みの空の列挙可能変数の1つを使用して、要素のないコレクションを表します。

状況によってnullを返す場合は、空のコレクションを返すように変更する場合があります。（そうでなければ、ライブラリメソッド（あなたのものではない）によって返されたnullを見つけている場合、それは残念なことであり、それらをラップして正規化します。）

https://stackoverflow.com/questions/1191919/what-does-linq-return-when-the-results-are-emptyも参照して ください

脇からヌル条件付き構文あなたの変数は、これまで残ることはできません、この問題を軽減するための別の技術がありますnull。

コレクションをパラメーターとして受け入れる関数を考えてみましょう。関数の目的上、nullおよびemptyが同等である場合null、先頭に決して含まれないようにすることができます。

public MyResult DoSomething(int a, IEnumerable<string> words)
{
    words = words ?? Enumerable.Empty<string>();

    if (!words.Any())
    {
        ...

他のメソッドからコレクションを取得するときにも同じことができます。

var words = GetWords() ?? Enumerable.Empty<string>();

（空のコレクションGetWordsなどの関数を制御する場合はnull、空のコレクションを最初に返すことをお勧めします。）

これで、コレクションに対して任意の操作を実行できます。これは、コレクションがのときに失敗する多くの操作を実行する必要がある場合に特に役立ちます。またnull、空の列挙型をループオーバーまたはクエリして同じ結果が得られる場合は、if条件を完全に削除できます。

このコードのクライアントとして、たとえば（（int []）null）.Any（）がfalseを返すことを期待するのは間違っていますか？

はい、単にあなたがC＃であり、その動作が適切に定義され、文書化されているからです。

独自のライブラリを作成している場合、または異なる例外カルチャで異なる言語を使用している場合は、falseを期待する方が合理的です。

個人的には、falseを返すことはプログラムをより堅牢にするより安全なアプローチであるように感じますが、少なくとも議論の余地はあります。

繰り返しnullチェックに悩まされる場合は、独自の 'IsNullOrEmpty（）'拡張メソッドを作成して、その名前でStringメソッドをミラーリングし、null-checkと.Any（）呼び出しの両方を単一の呼び出しにラップすることができます。

それ以外の場合、あなたの質問のコメントで@ 17の@ 17で言及されている解決策は、「標準」メソッドよりも短く、新しいヌル条件構文に精通している人には合理的に明らかです。

if(myCollection?.Any() == true)

このコードのクライアントとして、たとえば（（int []）null）.Any（）がfalseを返すことを期待するのは間違っていますか？

期待について疑問に思うなら、あなたは意図について考えなければなりません。

null とは非常に異なるものを意味します Enumerable.Empty<T>

Erik Eidtの回答で述べたようにnull、空のコレクションとの間に意味の違いがあります。

それらがどのように使用されることになっているかを一見しよう。

MicrosoftのアーキテクトKrzysztof CwalinaとBrad Abramsによって書かれた書籍「Framework Design Guidelines：Conventions、Idioms、and Patterns for Reusable .NET Libraries、2nd Edition」には、次のベストプラクティスが記載されています。

Xは、コレクションのプロパティまたはコレクションを返すメソッドからnull値を返しません。代わりに、空のコレクションまたは空の配列を返します。

最終的にデータベースからデータを取得するメソッドの呼び出しを検討してください。空の配列を受け取った場合、またはEnumerable.Empty<T>単にサンプルスペースが空の場合、つまり結果が空のセットである場合。nullただし、このコンテキストで受信すると、エラー状態を意味します。

Dan Wilsonのポテトの例えと同じ考え方で、データが空のセットであってもデータについて質問するのは理にかなっています。しかし、setがない場合は、あまり意味がありません。

なぜnullと空が異なるのかを説明する多くの答えがあり、それらが異なる扱いを受けるべきかどうかの両方を説明しようとする十分な意見があります。しかし、あなたは尋ねています：

このコードのクライアントとして、たとえば（（int []）null）.Any（）がfalseを返すことを期待するのは間違っていますか？

それは完全に合理的な期待です。あなたは、現在の行動を主張している他の誰かと同じように正しいです。私は現在の実装哲学に同意しますが、推進要因はコンテキスト外の考慮事項に基づいているだけではありません。

ことを考えるとAny()述語ずに本質的であるCount() > 0あなたは、このスニペットから何を期待し、その後？

List<int> list = null;
if (list.Count > 0) {}

またはジェネリック：

List<int> list = null;
if (list.Foo()) {}

あなたが期待してNullReferenceExceptionいると思います。

• Any()は拡張メソッドであり、拡張オブジェクトとスムーズに統合する必要があり、例外をスローすることは最も驚くべきことではありません。
• すべての.NET言語が拡張メソッドをサポートしているわけではありません。
• あなたはいつでも電話をかけることができますがEnumerable.Any(null)、そこで間違いなく期待していArgumentNullExceptionます。これは同じメソッドであり、フレームワークの他のほぼすべてと一致する必要があります。
• nullオブジェクトへのアクセスはプログラミングエラーであり、フレームワークはマジック値としてnullを強制するべきではありません。そのように使用する場合、それを処理するのはあなたの責任です。
• それは意見があり、あなたは1つの方法を考え、私は別の方法を考える。フレームワークは、可能な限り非標準化する必要があります。
• あなたは特別なケースを持っているなら、あなたはでなければならない、一貫した：あなたは、他のすべての拡張メソッドの詳細や、より高度に独断決定を取らなければならない：場合はCount()、その後容易な決断だと思わWhere()ないです。どうMax()？EMPTYリストに対して例外をスローしますが、EMPTYリストに対しても例外をスローするべきではありませんnullか？

ライブラリ設計者がLINQの前に行ったのnullは、有効な値（たとえばString.IsNullOrEmpty()）が明示的なメソッドを導入することで、既存の設計哲学と整合する必要があった場合です。とは言っても、書くのがかなり簡単な場合でも、2つの方法EmptyIfNull()とEmptyOrNull()便利かもしれません。

ジムは、ジャガイモをすべての袋に入れることになっています。そうでなければ私は彼を殺すつもりです。

ジムには、5つのジャガイモが入った袋があります。.Any()袋にジャガイモは入っていますか？

「はい」とあなたは言います。<= true

OK、ジムは今回住んでいます。

ジムはジャガイモをすべて取り出して食べます。袋の中に。（）ジャガイモがありますか？

「いいえ」とあなたは言います。<= false

ジムを殺す時間。

ジムは火でバッグを完全に焼却します。現在、バッグの中に任意のジャガイモがありますか？

「バッグはありません。」<= ArgumentNullException

ジムは生きるか死ぬべきか？まあ、これは予想していなかったので、裁定が必要です。Jimがこれを回避できるかどうかはバグですか？

あなたはできるのアノテーションを使用しますが、任意のヌル悪ふざけでこの道を入れていないことを知らせるために。

public bool Any( [NotNull] List bag ) 

ただし、ツールチェーンはそれをサポートする必要があります。つまり、最終的に小切手を書くことになります。

これが非常に面倒な場合は、簡単な拡張方法をお勧めします。

static public IEnumerable<T> NullToEmpty<T>(this IEnumerable<T> source)
{
    return (source == null) ? Enumerable.Empty<T>() : source;
}

これで次のことができます。

List<string> list = null;
var flag = list.NullToEmpty().Any( s => s == "Foo" );

...そしてフラグはに設定されfalseます。

これはC＃の拡張メソッドとその設計哲学に関する質問なので、この質問に答える最良の方法は、拡張メソッドの目的に関するMSDNのドキュメントを引用することだと思います。

拡張メソッドを使用すると、新しい派生型の作成、再コンパイル、または元の型の変更を行わずに、既存の型にメソッドを「追加」できます。拡張メソッドは特別な種類の静的メソッドですが、拡張タイプのインスタンスメソッドであるかのように呼び出されます。C＃、F＃、およびVisual Basicで記述されたクライアントコードの場合、拡張メソッドの呼び出しと、実際に型で定義されているメソッドの間に明確な違いはありません。

…

一般的に、拡張メソッドを控えめに実装することをお勧めします。可能な限り、既存の型を拡張する必要があるクライアントコードは、既存の型から派生した新しい型を作成することで拡張する必要があります。詳細については、継承を参照してください。

拡張メソッドを使用して、ソースコードを変更できない型を拡張する場合、その型の実装の変更により拡張メソッドが破損するリスクがあります。

特定のタイプに拡張メソッドを実装する場合、次の点に注意してください。

• 型で定義されたメソッドと同じシグネチャを持つ場合、拡張メソッドは呼び出されません。
• 拡張メソッドは、名前空間レベルでスコープに取り込まれます。たとえば、という名前の単一の名前空間に拡張メソッドを含む複数の静的クラスがある場合Extensions、それらはすべてusing Extensions;ディレクティブによってスコープに取り込まれます。

要約すると、拡張メソッドは、開発者が直接追加できない場合でも、特定の型にインスタンスメソッドを追加するように設計されています。また、インスタンスメソッドは、存在する場合は常に拡張メソッドをオーバーライドするため（インスタンスメソッド構文を使用して呼び出された場合）、メソッドを直接追加したりクラスを拡張したりできない場合にのみ行う必要があります。*

言い換えると、拡張メソッドはインスタンスメソッドと同じように動作する必要があります。これは、クライアントによってインスタンスメソッドにされる可能性があるためです。インスタンスメソッドはnull、呼び出されているオブジェクトがの場合にスローする必要があるため、拡張メソッドもスローする必要があります。

*補足として、これはまさにLINQのデザイナーが直面した状況です。C＃3.0がリリースされたとき、コレクションとループの両方でSystem.Collections.IEnumerableとを使用している何百万ものクライアントが既に存在していSystem.Collections.Generic.IEnumerable<T>ましたforeach。これらのクラスは、返されたIEnumeratorだけで2つのメソッドを持っていたオブジェクトCurrentとMoveNextそのような任意の追加の必要なインスタンスメソッド、追加、Count、Any、など、クライアントのこれらの何百万人を壊すことになるが。だから、（それがの点で実施することができるので、特にこの機能を提供するために、CurrentそしてMoveNext比較的容易に）、それらは任意の現存に適用することができる拡張メソッド、としてそれをリリースIEnumerableまた、より効率的な方法でクラスによって実装することもできます。C＃の設計者がLINQを初日にリリースすることを決めた場合、それはのインスタンスメソッドとしてIEnumerable提供され、それらのメソッドの既定のインターフェイス実装を提供する何らかのシステムを設計したでしょう。

ここでの顕著な点は、例外をスローする代わりにfalseを返すことで、コードの将来のリーダー/修飾子に関連する可能性のある情報を難読化することだと思います。

リストがnullになる可能性がある場合は、そのために別のロジックパスを用意することをお勧めします。予測する理由がなかったという望ましくない例外。

読みやすさと保守性は、毎回「余分な条件を記述する必要があります」に勝っています。

原則として、ほとんどのコードを書いて、主にNullを返さない（および他の同様の投稿）で説明されている理由により、呼び出し元がnullデータを渡さないようにする責任があると想定しています。nullの概念はよく理解されていないことが多く、そのため、実用的な限り変数を事前に初期化することをお勧めします。妥当なAPIを使用していると仮定すると、理想的にはnull値を取得しないようにする必要があるため、nullをチェックする必要はありません。他の答えが述べているように、nullのポイントは、続行する前に作業する有効なオブジェクト（「バッグ」など）があることを確認することです。これはの機能ではなくAny、言語の機能です自体。nullオブジェクトは存在しないため、ほとんどの操作はできません。私は車を持っていないことを除いて、私の車で店に運転するように頼むようなものです。したがって、あなたは私の車を使って店に行く方法がありません。文字通り存在しないものに対して操作を実行するのは無意味です。

nullを使用する実用的なケースがあります。たとえば、要求された情報を文字通り入手できない場合などです（たとえば、私の年齢を尋ねた場合、この時点で答える可能性が最も高い選択肢は「わからない」 「これはヌル値です）。ただし、ほとんどの場合、少なくとも変数が初期化されているかどうかを知っている必要があります。そうでない場合は、コードを強化する必要があることをお勧めします。プログラムまたは関数で最初に行うことは、値を使用する前に初期化することです。変数がnullでないことを保証できるため、null値をチェックする必要があることはまれです。取得するのは良い習慣であり、変数を初期化する頻度を高くするほど、nullをチェックする必要が少なくなります。