戻り値が存在しない関数/メソッドからNULLまたは空の値を返す方が良いですか？

ここで推奨事項を探しています。戻り値が存在しないか判断できない場合に、メソッドからNULLまたは空の値を返す方が良いかどうかに苦労しています。

例として、次の2つの方法を使用します。

string ReverseString(string stringToReverse) // takes a string and reverses it.
Person FindPerson(int personID)    // finds a Person with a matching personID.

ではReverseString()、戻り値の型が文字列であるため、呼び出し側はそれを期待しているため、空の文字列を返します。また、この方法では、呼び出し元はNULLが返されたかどうかを確認する必要がありません。

でFindPerson()、NULLを返す方が適切なようです。NULLまたは空のPersonオブジェクト（new Person()）が返されるかどうかに関係なく、呼び出し側は、何かを行う前に（呼び出しなどUpdateName()）PersonオブジェクトがNULLまたは空であるかどうかを確認する必要があります。ここでNULLを返すだけで、呼び出し側はNULLをチェックするだけでよいのはなぜですか。

他の誰かがこれに苦労していますか？どんな助けや洞察も大歓迎です。

StackOverflowは、このQ＆Aでこの正確なトピックに関する良い議論をしています。トップ評価の質問で、クロノズは次のように述べています。

使用可能なデータがないことを示す場合は、通常、nullを返すことをお勧めします。

空のオブジェクトはデータが返されたことを意味しますが、nullを返すことは何も返されなかったことを明確に示します。

さらに、オブジェクトのメンバーにアクセスしようとすると、nullを返すとnull例外が発生します。これは、バグのあるコードを強調表示するのに役立ちます。空のオブジェクトのメンバーへのアクセスは失敗しません。つまり、バグが発見されない可能性があります。

個人的には、文字列を返す関数に空の文字列を返し、配置する必要があるエラー処理の量を最小限に抑えることが好きです。ただし、作業するグループが同じ規則に従うようにする必要があります。そうしないと、この決定の利点が得られません。

ただし、SOの回答の投稿者が述べたように、データが返されるかどうかに疑いがないように、オブジェクトが予想される場合はおそらくnullが返される必要があります。

最後に、物事を行うための単一の最良の方法はありません。チームのコンセンサスを構築すると、最終的にチームのベストプラクティスが促進されます。

私が書くすべてのコードでnullは、関数から戻ることを避けています。Clean Codeでそれを読みました。

使用の問題nullは、インターフェースを使用している人nullは、可能な結果であるかどうか、およびnot null参照タイプがないために確認する必要があるかどうかを知らないことです。

F＃では、あなたは返すことができますoptionすることができタイプ、some(Person)またはnone、それは彼らがチェックする必要があり、発信者には自明です。

類似のC＃（アンチ）パターンはTry...メソッドです：

public bool TryFindPerson(int personId, out Person result);

今私は、人々は、彼らが言っている知って嫌いTry...：出力パラメータを有する純粋な機能のアイデアを破るが、それはより実際に何ら変わりませんので、パターンを

class FindResult<T>
{
   public FindResult(bool found, T result)
   {
       this.Found = found;
       this.Result = result;
   }

   public bool Found { get; private set; }
   // Only valid if Found is true
   public T Result { get; private set;
}

public FindResult<Person> FindPerson(int personId);

...そして正直に言うと、.NETフレームワークによって内部的に使用されているため、すべての .NETプログラマーがTry...パターンについて知っていると仮定できます。それは彼らが何をするのかを理解するためにドキュメントを読む必要がないことを意味します。それは機能に対する純粋主義者の見方に固執するよりも重要です（それresultはoutパラメーターではなくパラメーターであると理解refする）。

TryFindPersonあなたがそれを見つけることができないことは完全に正常であることを示すように見えるので、私は行きます。

一方、存在しないものを呼び出し側が提供するpersonIdという論理的な理由がない場合は、おそらく次のようにします。

public Person GetPerson(int personId);

...そして、無効な場合は例外をスローします。Get...プレフィックスは、呼び出し側は、それが成功する必要があります知っていることを意味します。

エンタープライズアプリケーションアーキテクチャのパターンから、Martin FowlerのSpecial Caseパターンを試すことができます。

ヌルはオブジェクト指向プログラムでは扱いにくいものです。ヌルはポリモーフィズムを打ち負かすからです。通常、指定された型の変数参照でfooを自由に呼び出すことができます。アイテムが正確な型であるかサブクラスであるかを心配する必要はありません。強く型付けされた言語では、呼び出しが正しいことをコンパイラにチェックさせることさえできます。ただし、変数にはnullを含めることができるため、nullでメッセージを呼び出すと実行時エラーが発生する場合があります。これにより、わかりやすいスタックトレースが得られます。

変数がnullになる可能性がある場合は、nullが存在する場合に正しいことを行うために、nullテストコードで変数を囲むことを忘れないでください。多くの場合、正しいことは多くのコンテキストで同じであるため、多くの場所で同様のコードを書くことになり、コードの重複の罪を犯します。

Nullはこのような問題の一般的な例であり、他のNullは定期的に発生します。数体系では、無限大に対処する必要があります。無限には、実数の通常の不変式を破る加算などの特別なルールがあります。ビジネスソフトウェアでの私の最も初期の経験の1つは、「占有者」と呼ばれる、完全には知られていないユーティリティ顧客との経験でした。これらはすべて、型の通常の動作を変更することを意味します。

nullまたは何らかの奇妙な値を返す代わりに、呼び出し元が期待するものと同じインターフェースを持つ特別なケースを返します。

私はReverseString()逆の文字列を返すと思うだろう、それがIllegalArgumentException渡された場合に投げるだろうNull。

NullObjectパターンにFindPerson()従うか、常に何かを見つけることができるのであれば、何かを見つけられないという未確認の例外を発生させるべきだと思います。

対処しNullなければならないことは避けるべきです。あるNull言語では、と呼ばれてきた数十億ドル規模間違いそれは発明者で！

私はそれを10億ドルの間違いと呼んでいます。それは1965年のnull参照の発明でした。当時、私はオブジェクト指向言語（ALGOL W）での参照のための最初の包括的な型システムを設計していました。

私の目標は、コンパイラによって自動的に実行されるチェックを使用して、参照のすべての使用が絶対に安全であることを保証することでした。しかし、実装が非常に簡単だったという理由だけで、null参照を挿入する誘惑に抵抗することはできませんでした。

これにより、無数のエラー、脆弱性、およびシステムクラッシュが発生し、過去40年間で数十億ドルの痛みと損害をもたらした可能性があります。

近年、MicrosoftのPREfixやPREfastなどの多くのプログラムアナライザーを使用して参照をチェックし、null以外のリスクがある場合は警告を発します。Spec＃のような最近のプログラミング言語では、非ヌル参照の宣言が導入されています。これが解決策であり、1965年に拒否しました。

トニー・ホア

Optionを返します。NullPointerExceptionのリスクなしに、異なる無効な値を返すことのすべての利点（コレクションに空の値を含めることができるなど）。

私はこの議論の両側を見て、コードをきれいに保ち、余分なエラー処理ブロックを避けるためなど、いくつかのかなり影響力のある声（例えば、ファウラー）がnullを返さないことを提唱しています

ただし、nullを返すことを支持する傾向があります。メソッドの呼び出しには重要な違いがあり、応答するデータがなく、応答するのでこの空のStringがあります。

Personクラスを参照する議論のいくつかを見てきましたので、クラスのインスタンスを検索しようとするシナリオを考えてください。ファインダー属性（IDなど）を渡すと、クライアントはすぐにnullをチェックして、値が見つからなかったかどうかを確認できます。これは必ずしも例外ではないため（例外は不要）、明確に文書化する必要があります。はい、これにはクライアント側の厳密さが必要です。いいえ、それは悪いことではないと思います。

ここで、有効なPersonオブジェクトを返す代替手段を考えてみてください...それには何も含まれていません。すべての値（name、address、favoriteDrink）にnullを入れますか、それとも有効だが空のオブジェクトをそれらに追加しますか？クライアントは、実際の人物が見つからなかったことをどのように判断しますか？名前がnullではなく空の文字列であるかどうかを確認する必要がありますか？この種のことは、実際にnullをチェックして先に進んだ場合と比べて、実際に同じくらいまたはそれ以上のコードの乱雑さと条件文につながるのではないでしょうか？

繰り返しますが、この議論のどちら側にも私が同意できる点がありますが、これはほとんどの人にとって最も理にかなっています（コードをより保守しやすくします）。

アイテムが存在するかどうかを知る必要がある場合はnullを返します。それ以外の場合、期待されるデータ型を返します。これは、アイテムのリストを返す場合に特に当てはまります。通常、呼び出し元がリストを必要としている場合、リストを反復処理することを想定すると安全です。多くの（ほとんど？すべて？）言語は、nullを反復しようとすると失敗しますが、空のリストを反復すると失敗します。

このようなコードを試して使用すると、失敗するだけでイライラします：

for thing in get_list_of_things() {
    do_something_clever(thing)
}

私は何も存在しないときケースのための特別なケースを追加する必要はありません物事が。

メソッドのセマンティクスに依存します。指定することもできますが、メソッドは「Not null」のみを受け入れます。Javaでは、いくつかのメタデータアノテーションを使用してそれを宣言できます。

string ReverseString(@NotNull String stringToReverse)

何らかの方法で戻り値を指定する必要があります。宣言すると、NotNull値のみを受け入れ、空の文字列を返すようにバインドされます（入力も空の文字列だった場合）。

2番目のケースは、そのセマンティクスが少し複雑です。このメソッドがその主キー（およびその人物が存在すると予想される）によって誰かを返す場合、より良い方法は例外をスローすることです。

Person FindPerson(int personID)

推測されたIDで人を検索する場合（奇妙に思えますが）、そのメソッドを@Nullableとして宣言する方が良いでしょう。

可能な限りNull Objectパターンを使用することをお勧めします。メソッドを呼び出すときにコードを簡素化し、次のようないコードを読むことはありません

if (someObject != null && someObject.someMethod () != whateverValue)

たとえば、あるパターンに一致するオブジェクトのコレクションをメソッドが返す場合、空のコレクションを返すことはを返すよりも意味がありnull、この空のコレクションを繰り返し処理してもパフォーマンスはほとんど低下しません。別のケースは、データを記録するために使用されるクラスインスタンスを返すメソッドnullですnull。返される参照がであるかどうかをユーザーが常にチェックすることを強制しないため、私の意見では望ましいNullオブジェクトを返します。

返すnullことが理にかなっている場合（findPerson ()たとえば、メソッドを呼び出す）、少なくともオブジェクトが存在する場合に返すメソッドを提供しようとします（personExists (int personId)たとえば）、別の例はJavaのcontainsKey ()メソッドMapです）。目的のオブジェクトが利用できない可能性があることを簡単に確認できるため、呼び出し元のコードが簡潔になります（人が存在せず、キーがマップに存在しない）。null私の意見では、参照がコードを難読化するかどうかを絶えずチェックすることでわかります。

次の条件が当てはまる場合にのみ、nullを返すのが最適です。

• 通常の操作ではnullの結果が期待されます。何らかの合理的な状況で人を見つけることができない可能性があるため、nullを返すfindPerson（）は問題ありません。ただし、（たとえばsaveMyImportantData（）と呼ばれる関数で）本当に予期しないエラーである場合は、例外をスローする必要があります。名前にはヒントがあります-例外は例外的な状況のためです！
• nullは"not found / no value"を意味するために使用されます。他の何かを意味する場合は、別の何かを返します！良い例は、InfinityまたはNaNを返す浮動小数点演算です。これらは特定の意味を持つ値であるため、ここでnullを返すと非常に混乱します。
• この関数は、findPerson（）などの単一の値を返すことを目的としています。findAllOldPeople（）などのコレクションを返すように設計されている場合は、空のコレクションが最適です。この結果として、コレクションを返す関数がnullを返すことはありません。

さらに、関数がnullを返すことができるという事実を必ず文書化してください。

これらの規則に従えば、nullはほとんど無害です。nullのチェックを忘れると、通常はすぐにNullPointerExceptionが発生することに注意してください。これは通常、修正が非常に簡単なバグです。このフェイルファーストアプローチは、例外をスローせずにシステムを静かに伝播し、データを破壊する可能性のある偽の戻り値（空の文字列など）よりもはるかに優れています。

最後に、質問にリストされている2つの関数にこれらのルールを適用する場合：

• FindPerson-人が見つからなかった場合、この関数はnullを返すことが適切です
• ReverseString-文字列を渡した場合、結果の検索に失敗することはないようです（空の文字列を含むすべての文字列を逆にすることができるため）。そのため、nullを返すことはありません。何か問題が発生した場合（メモリ不足？）、例外をスローする必要があります。

私の意見では、NULLを返すこと、空の結果（空の文字列または空のリストなど）を返すこと、および例外をスローすることには違いがあります。

私は通常、次のアプローチを取ります。関数またはメソッドf（v1、...、vn）呼び出しを関数のアプリケーションと見なします

f : S x T1 x ... x Tn -> T

ここで、S itは「世界の状態」T1、...、Tnは入力パラメーターのタイプ、Tは戻り値のタイプです。

最初にこの関数を定義しようとします。関数が部分的である場合（つまり、定義されていない入力値がいくつかある場合）、NULLを返してこれを通知します。これは、計算を正常に終了させ、要求した関数が指定された入力で定義されていないことを通知するためです。たとえば、戻り値として空の文字列を使用すると、関数が入力で定義され、空の文字列が正しい結果になる可能性があるため、あいまいです。

部分的な関数を適用しているため、呼び出しコード内のNULLポインターの追加チェックが必要だと思います。これは、指定された入力に対して関数が定義されていない場合に呼び出されるメソッドのタスクです。

計算を実行できないエラーには例外を使用することを好みます（つまり、答えを見つけることができませんでした）。

たとえば、クラスCustomerがあり、メソッドを実装するとします。

Customer findCustomer(String customerCode)

コードでアプリケーションデータベース内の顧客を検索します。この方法では、

• クエリが成功した場合、Customerクラスのオブジェクトを返します。
• クエリで顧客が見つからない場合はnullを返します。
• データベースに接続できない場合は、例外をスローします。

ヌルの追加チェック、例えば

Customer customer = findCustomer("...");
if (customer != null && customer.getOrders() > 0)
{
    ...
}

は私がやっていることのセマンティクスの一部であり、コードを読みやすくするために「スキップ」するだけではありません。コードを単純化するためだけに、問題のセマンティクスを単純化することは良い習慣ではないと思います。

もちろん、nullのチェックは非常に頻繁に行われるため、言語がそのための特別な構文をサポートしていると良いでしょう。

クラスのnullオブジェクトを他のすべてのオブジェクトと区別できる限り、Null Objectパターン（Lafが示唆する）の使用も検討します。

コレクションを返すメソッドは空を返す必要がありますが、他のオブジェクトはnullを返す可能性があります。コレクションの場合、オブジェクトはあるが要素が存在しないことがあるため、呼び出し側は両方ではなくサイズだけを検証します。

私には2つのケースがあります。ある種のリストを返す場合は、何があっても常にリストを返す必要があります。リストに何も入力しない場合は空にします。

議論が見られる唯一のケースは、単一のアイテムを返すときです。このような状況で障害が発生した場合、物事を迅速に失敗させることに基づいて、nullを返すことを好みます。

nullオブジェクトを返し、呼び出し元が実際のオブジェクトを必要とした場合、それらは先に進み、nullオブジェクトを使用して予期しない動作を生成しようとする可能性があります。彼らが状況に対処することを忘れた場合、私はそれがルーチンがブームになるのが良いと思います。何かが間違っている場合は、できるだけ早く例外が必要です。この方法でバグを出荷する可能性は低くなります。

Maybe型コンストラクタについてすでに人々が言っ​​たことに加えて：

NPEを危険にさらさないこととは別に、もう1つの大きなメリットはセマンティックです。純粋な関数を扱う関数の世界では、適用されたときに戻り値とまったく同じ関数を作成しようとしています。の場合を考えてみましょうString.reverse()。これは、特定の文字列がその文字列の逆バージョンを表す関数です。すべての文字列を逆にすることができるため、この文字列が存在することはわかっています（文字列は基本的に順序付けられた文字のセットです）。

さて、どうでしょうfindCustomer(int id)？この関数は、指定されたIDを持つ顧客を表します。これは、存在する場合と存在しない場合があります。しかし、あなたは本当にこの関数は、与えられたIDを顧客に返す」と言うことはできませんので機能は、単一の戻り値を持って、覚えORそれが返されますnull。

これは、nullnullオブジェクトを返すことと返すことの両方に関する私の主な問題です。彼らは誤解を招きます。null顧客ではなく、「顧客の不在」でもありません。何もありません。これは、NOTHINGへの型のないポインタです。非常に低レベルで非常にく、非常にエラーが発生しやすい。ここでは、nullオブジェクトもかなり誤解を招く可能性があります。nullの顧客は顧客です。1つも存在しないわけでも、IDを要求された顧客でもないので、それを返すのは間違っています。これは私が要求した顧客ではありませんが、顧客を返品したと主張しています。IDが間違っています。明らかにこれはバグです。メソッド名と署名によって提案された契約を破ります。クライアントコードが設計に関することを引き受けるか、ドキュメントを読む必要があります。

これらの問題は両方ともによって解決されますMaybe Customer。突然、「この関数は特定のIDを持つ顧客を表す」と言っているわけではありません。「この関数は、指定されたIDの顧客が存在する場合にそれを表します。現在、その機能について非常に明確かつ明確になっています。存在しないIDを持つ顧客を求めると、受け取りNothingます。よりnullだけでなく、NPEのリスクのため？。しかし、またの種類があるためNothingだけのものではありませんMaybe。それはだMaybe Customer。それはセマンティックな意味を持っている。それは、具体的には、顧客が存在しないことを示す、「顧客の不在」を意味します。

nullのもう1つの問題は、当然、あいまいであることです。顧客が見つからなかったのか、db接続エラーがあったのか、その顧客を見ることが許可されていないだけですか？

このようなエラーケースを処理する必要がある場合、それらのバージョンに例外をスローするか、または（この方法をお勧めします）を返すことができEither CustomerLoadError Customerます。これには、すべての利点がMaybe Customerありますが、何がうまくいかないかを指定することもできます。

私が望んでいる主なことは、その署名で関数のコントラクトをキャプチャすることです。物事を仮定しないで、つかの間の慣習に依存せず、明示的である。

1）関数のセマンティックが何も返さないという場合、呼び出し元はそれをテストしなければなりません。あなたのお金を取って誰にも与えないでください。

2）意味的に常に何かを返す（またはスローする）関数を作成するのに適しています。

ロガー、それはロガーが定義されていない場合はログインしていないロガーを返すために意味をなします。コレクションを返すとき、空のセットはセットであり、空ではないので、コレクションを返すことはほとんど意味がありません（コレクション自体がデータではなく、コレクション自体がデータである「十分に低いレベル」を除く）。

人の例、私は2つの機能、nullを返し、二それがスロー1つを有するの道を（それが遅延ロードのプロキシオブジェクトによって複雑になるが、そこに、負荷対IIRCを取得する）「休止」に行くだろう。

• アプリケーションがデータが利用可能であると予想しているが、データが利用可能でない場合、NULLが返されます。たとえば、郵便番号に基づいてCITYを返すサービスは、都市が見つからない場合はnullを返す必要があります。呼び出し元は、nullを処理するか爆破するかを決定できます。

• 2つの可能性がある場合、空のリストが返されます。利用可能なデータまたは利用可能なデータがありません。たとえば、人口が特定の数を超えている場合にCITY（s）を返すサービス。指定された基準を満たすデータがない場合、空のリストを返すことができます。

NULLを返すことは、オブジェクト指向の世界ではひどい設計です。一言で言えば、NULLを使用すると次のようになります。

• アドホックエラー処理（例外ではなく）
• あいまいなセマンティック
• 速く失敗する代わりに遅い
• コンピューター思考とオブジェクト思考
• 可変で不完全なオブジェクト

詳細な説明については、このブログ投稿を確認してください：http : //www.yegor256.com/2014/05/13/why-null-is-bad.html