削除するアイテムが指定されていない場合、サービスは例外をスローするかリターンする必要があります

次のように表すことができるコードがあります：

public class ItemService {

    public void DeleteItems(IEnumerable<Item> items)
    {
        // Save us from possible NullReferenceException below.
        if(items == null)
            return;

        foreach(var item in items)
        {
            // For the purpose of this example, lets say I have to iterate over them.
            // Go to database and delete them.
        }
    }
}

今、私はこれが正しいアプローチなのか、それとも例外を投げるべきなのか疑問に思っています。返すことは空のコレクションを反復することと同じであるため、例外を避けることができます。つまり、重要なコードは実行されませんが、一方でコードのどこかに問題を隠している可能性がありますパラメータ？これは、コードのどこかに問題があることを示している可能性があります。DeleteItemsnull

これは私が通常サービスのメソッドで抱えている問題です。それらのほとんどは何かをして結果を返さないため、誰かが無効な情報を渡すと、サービスが行うことは何もないので戻ります。

これらは2つの異なる質問です。

受け入れnullますか？それはnull、コードベースに関する一般的なポリシーに依存します。私の意見でnullは、明示的に文書化されている場合を除き、すべての場所を禁止することは非常に良い習慣ですが、コードベースが既に持っている慣習に従うことはさらに良い習慣です。

空のコレクションを受け入れますか？私の意見では：はい、絶対に。すべての呼び出し元を空でないコレクションに制限するのは、数学的に正しいことをするよりもはるかに労力がかかります-ゼロという概念に疑問を抱いている一部の開発者を驚かせても。

ヌル値

@KilianFothが既に言ったように、あなたの一般的な方針に固執してください。それがnull空のリストの「速記」として扱う場合は、そのようにします。

null値に関する一貫したポリシーがない場合は、次のものをお勧めします。

null「通常」タイプでは表現できない状況を表すために予約する必要があります。例えば、null「わからない」を表すために使用します。そして、この値を不注意に使用しようとするすべての人が例外を取得するため、これは正しい選択です。これは正しいことです。

null空のリストの省略形として使用しても、要素がゼロのリストである完全な表現がすでに存在するため、その方法は限定されません。また、リストを処理するコードのすべての部分で有効な略記をチェックすることを強制するため、技術的に悪い選択ですnull。

空のリスト

以下のためDeleteItems()の方法、空のリストを渡すと、効果的に何もしないことを意味します。私はそれを引数として許可し、例外をスローするのではなく、ただすぐに戻ります。

もちろん、呼び出し元は最初にゼロ要素をチェックしDeleteItems()、その場合は呼び出しをスキップできます。Web APIについて話している場合、効率上の理由から、呼び出し側は不必要なトラフィックと往復遅延を避けるために実際にそれを行う必要があります。しかし、私はあなたのAPIがそれを強制するべきではないと思います。

例外をスローし、呼び出し元のコードでnullを処理します。

設計ルールとして、パラメーター値としてnullを避けるようにしてください。nullは実際には例外であるため、一般にNullPointerExceptionsを減らします。

それに加えて、残りのコードを見てください。これがプロジェクトで一般的なパターンである場合、一貫性を保ちます。

一般的に、例外のスローは例外的な状況、つまり、コードに現在のコンテキストで実行する適切なアクションがない場合のために予約する必要があります。

この思考プロセスをこの状況に適用できます。これがパブリックメソッドを持つパブリッククラスであることを考えると、パブリックAPIがあり、理論的には何が渡されるかを制御することはできません。

あなたのコードは、それを呼び出しているものについてのコンテキストを持たない（そうすべきではない）ため、null値で合理的にできることは何もない。これは確かに候補ですArgumentNullException。

この質問は例外に関するものではなくnull、有効な議論であることのようです。

そのため、何よりもまず、nullそのメソッドの引数に許容値かどうかを判断する必要があります。そうであれば、例外は必要ありません。そうでない場合は、例外が必要です。

許可するかどうかnullは、多くのGoogleヒットが示すように、議論の余地があります。つまり、明確な答えを得ることができず、あなたが働いている場所での意見と伝統次第です。

競合の別の領域は、誤ったパラメーターを「修正」しようとしていない限り、ライブラリー関数がそのようなことについて本当に厳しいか、または可能な限り寛大であるかどうかです。これを、ネットワークプロトコル、メール転送などの世界と比較してください（プログラミングのメソッドと同様に、インターフェイスコントラクトです）。そこでは、通常、送信者はプロトコルにできるだけ厳密に従う必要がありますが、受信者は邪魔にならないようにして、何でも処理できるようにするというポリシーがあります。

決定する必要があります：null処理のようなかなり大きなポリシーを強制するのは、実際にはライブラリメソッドの仕事ですか？特に、ライブラリが他の人（異なるポリシーを持っている人）によっても使用されている場合。

他の同様のコード（「ライブラリ」スタイルのコード）の99％が別の方法で行わない限りnull、値を許可し、そのセマンティクスを定義および文書化する（つまり、null = empty arrayこの場合）側で間違いを犯し、例外をスローしません'円形。