入力が技術的に有効であるが、満足できない場合の例外と空の結果セット

私は公開リリースを目的としたライブラリを開発しています。オブジェクトのセットを操作するためのさまざまなメソッドが含まれています-セットを生成、検査、パーティション分割、新しいフォームに投影します。関連する場合IEnumerableは、NuGetパッケージとしてリリースされるLINQスタイルの拡張を含むC＃クラスライブラリです。

このライブラリの一部のメソッドには、満たされない入力パラメーターを指定できます。たとえば、組み合わせメソッドには、m個のアイテムのソースセットから構築できるn個のアイテムのすべてのセットを生成するメソッドがあります。たとえば、次のセットを考えます：

1、2、3、4、5

2の組み合わせを要求すると、次の結果が得られます。

1、2
1、3
1、4
等...
5、3
5、4

現在、3つのアイテムのセットを提供し、各アイテムを1回しか使用できないというオプションを設定しながら、4つのアイテムの組み合わせを要求するなど、実行できないことを要求することは明らかに可能です。

このシナリオでは、各パラメーターは個別に有効です。

• ソースコレクションはnullではなく、アイテムが含まれています
• 要求された組み合わせのサイズは、ゼロ以外の正の整数です
• 要求されたモード（各アイテムを1回のみ使用）は有効な選択です

ただし、パラメーターの状態を一緒にすると問題が発生します。

このシナリオでは、メソッドが例外をスローすることを期待しますか（例：）InvalidOperationException、または空のコレクションを返しますか？どちらも私にとって有効なようです：

• あなたは、の組み合わせを生成することができないn個のセットから項目をm個の項目N> M君はそれゆえ、一度だけ、各アイテムの使用を許可しているので、この操作は不可能と考えることができる場合InvalidOperationException。
• n> mが空のセットである場合にm個のアイテムから生成できるサイズnの組み合わせのセット。組み合わせは作成できません。

空のセットの引数

私の最初の懸念は、サイズが不明なデータセットを処理する場合、例外が慣用的なLINQスタイルのメソッドのチェーンを妨げることです。言い換えれば、あなたはこのようなことをしたいと思うかもしれません：

var result = someInputSet
    .CombinationsOf(4, CombinationsGenerationMode.Distinct)
    .Select(combo => /* do some operation to a combination */)
    .ToList();

入力セットのサイズが可変の場合、このコードの動作は予測できません。場合は.CombinationsOf()、例外をスローしたときsomeInputSetよりも少ない4つの要素を持っている場合、このコードがします時々、いくつかの事前チェックせずに、実行時に失敗します。上記の例では、このチェックは簡単ですが、より長いLINQチェーンの途中で呼び出す場合、これは面倒になります。それが空のセットを返す場合、空になりますresult。

例外の引数

私の2番目の懸念は、空のセットを返すと問題が隠れる可能性があることです-LINQのチェーンの途中でこのメソッドを呼び出して静かに空のセットを返す場合、後でいくつかの手順で問題が発生するか、空の結果セット。入力セットに何かが確実に含まれていた場合、それがどのように発生したかは明らかではないかもしれません。

あなたは何を期待しますか、それに対するあなたの議論は何ですか？

空のセットを返す

私は空のセットを期待しています：

各番号を1回しか使用できない場合、3つのセットから4つの番号の0個の組み合わせ

疑わしい場合は、他の人に尋ねてください。

サンプル関数は、Pythonで非常によく似た関数ですitertools.combinations。仕組みを見てみましょう。

>>> import itertools
>>> input = [1, 2, 3, 4, 5]
>>> list(itertools.combinations(input, 2))
[(1, 2), (1, 3), (1, 4), (1, 5), (2, 3), (2, 4), (2, 5), (3, 4), (3, 5), (4, 5)]
>>> list(itertools.combinations(input, 5))
[(1, 2, 3, 4, 5)]
>>> list(itertools.combinations(input, 6))
[]

そして、それは私にとって完全にいい感じです。繰り返し処理できる結果を期待していましたが、結果が得られました。

しかし、明らかに、あなたが何か愚かなことを尋ねるとしたら：

>>> list(itertools.combinations(input, -1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: r must be non-negative

したがって、すべてのパラメーターが検証されたが、結果が空のセットであり、空のセットを返す場合、それを行うのはあなただけではありません。

コメントで@Bakuriuが言ったように、これはのSQLようなクエリでも同じですSELECT <columns> FROM <table> WHERE <conditions>。限り<columns>、<table>、<conditions>うまく形成されて形成され、既存の名前を参照している、あなたはお互いを除外する条件のセットを構築することができます。結果のクエリは、をスローする代わりに行を生成しませんInvalidConditionsError。

素人の言葉で：

• エラーがある場合は、例外を発生させる必要があります。エラーが発生した場所を正確に知るために、単一のチェーンコールではなく、ステップで物事を行う必要があります。
• エラーはないが、結果のセットが空の場合、例外を発生させず、空のセットを返します。空のセットは有効なセットです。

ユアンの答えには同意しますが、具体的な理由を付け加えたいと思います。

あなたは数学的操作を扱っているので、同じ数学的定義に従うことは良いアドバイスかもしれません。数学的な観点から、nセットのrセット（つまりnCr）の数は、すべてのr> n> = 0に対して明確に定義されています。これはゼロです。したがって、数学的な観点からは、空のセットを返すことが期待されます。

例外を使用するかどうかを判断する良い方法は、トランザクションに関係する人々を想像することです。

例としてファイルの内容を取得することを考えます：

1. 「does n't exist.txt」というファイルの内容を取得してください

   a。「内容は次のとおりです。文字の空のコレクション」

   b。「問題があります。そのファイルは存在しません。何をすべきかわかりません！」

2. 「存在するがempty.txt」というファイルの内容を取得してください

   a。「内容は次のとおりです。文字の空のコレクション」

   b。「ええ、問題があります。このファイルには何もありません。何をすべきかわかりません！」

疑いの余地はありませんが、ほとんどの人にとって、「問題があります」というのは、ファイルが存在しない場合に意味があり、ファイルが空の場合は「文字の空のコレクション」を返します。

したがって、同じアプローチを例に適用します。

3. 4つのアイテムのすべての組み合わせを教えてください {1, 2, 3}

   a。何もありません、空のセットです。

   b。問題があります、私は何をすべきかわかりません。

繰り返しますが、「問題があります」は、たとえばnullアイテムのセットとして提供された場合に意味がありますが、「ここに空のセットがあります」は上記の要求に対する賢明な応答のようです。

空の値を返すことが問題を隠している場合（たとえば、ファイルの欠落、a null）、通常は代わりに例外を使用する必要があります（選択した言語がoption/maybe型をサポートしている場合を除き、より意味があります）。それ以外の場合、空の値を返すとコストが単純化される可能性が高く、最小限の驚きの原則により適合します。

汎用ライブラリーであるため、私の本能はエンドユーザーに選択させることです。

私たちが持っているのParse()と同じようにTryParse()、関数から必要な出力に応じて使用するオプションを持つことができます。関数の単一のバージョンを選択することについて議論するよりも、例外をスローするために関数ラッパーを作成および保守する時間を短縮できます。

関数が呼び出されたときに提供される引数を検証する必要があります。そして実際のところ、無効な引数を処理する方法を知りたいのです。複数の引数が互いに依存しているという事実は、引数を検証するという事実を補うものではありません。

したがって、ユーザーが何が間違っているかを理解するために必要な情報を提供するArgumentExceptionに投票します。

例として、public static TSource ElementAt<TSource>(this IEnumerable<TSource>, Int32)Linq の関数を確認し ます。インデックスが0より小さいか、ソース内の要素の数以上である場合、ArgumentOutOfRangeExceptionをスローします。したがって、インデックスは、呼び出し元によって提供された列挙可能に関して検証されます。

次のいずれかを実行する必要があります（ただし、負の数の組み合わせなどの基本的な問題を継続的にスローします）。

1. 入力が無意味な場合に空のセットを返す実装と、スローする実装の2つの実装を提供します。それらCombinationsOfを呼び出してみてくださいCombinationsOfWithInputCheck。またはあなたが好きなもの。これを逆にすると、入力チェックの方が短い名前になり、リストの方が短い名前になりCombinationsOfAllowInconsistentParametersます。

2. LinqメソッドのIEnumerable場合は、説明したとおりの前提で空を返します。次に、これらのLinqメソッドをライブラリに追加します。

   public static class EnumerableExtensions {
      public static IEnumerable<T> ThrowIfEmpty<T>(this IEnumerable<T> input) {
         return input.IfEmpty<T>(() => {
            throw new InvalidOperationException("An enumerable was unexpectedly empty");
         });
      }
   
      public static IEnumerable<T> IfEmpty<T>(
         this IEnumerable<T> input,
         Action callbackIfEmpty
      ) {
         var enumerator = input.GetEnumerator();
         if (!enumerator.MoveNext()) {
            // Safe because if this throws, we'll never run the return statement below
            callbackIfEmpty();
         }
         return EnumeratePrimedEnumerator(enumerator);
      }
   
      private static IEnumerable<T> EnumeratePrimedEnumerator<T>(
         IEnumerator<T> primedEnumerator
      ) {
         yield return primedEnumerator.Current;
         while (primedEnumerator.MoveNext()) {
            yield return primedEnumerator.Current;
         }
      }
   }
   

   最後に、次のように使用します：

   var result = someInputSet
      .CombinationsOf(4, CombinationsGenerationMode.Distinct)
      .ThrowIfEmpty()
      .Select(combo => /* do some operation to a combination */)
      .ToList();
   

   またはこのように：

   var result = someInputSet
      .CombinationsOf(4, CombinationsGenerationMode.Distinct)
      .IfEmpty(() => _log.Warning(
         $@"Unexpectedly received no results when creating combinations for {
            nameof(someInputSet)}"
      ))
      .Select(combo => /* do some operation to a combination */)
      .ToList();
   

   linqチェーンが列挙されるときではなく、linqチェーンが作成されるときにスローまたはアクション動作が発生するためには、パブリックメソッドとは異なるプライベートメソッドが必要であることに注意してください。あなたは欲しい、それはすぐにスローします。

   ただし、当然ながら、アイテムがあるかどうかを判断するには、少なくとも最初のアイテムを列挙する必要があります。これは潜在的な欠点であり、将来の視聴者はThrowIfEmptyメソッドが少なくとも1つの項目を列挙する必要があると非常に簡単に推論できるため、驚くことはないはずです。しかし、あなたは決して知りません。これをより明確にすることができThrowIfEmptyByEnumeratingAndReEmittingFirstItemます。しかし、それは巨大な行き過ぎのようです。

＃2は非常に素晴らしいと思います！これで、呼び出し元のコードに力が加わり、コードの次のリーダーはそれが何をしているかを正確に理解し、予期しない例外に対処する必要がなくなります。

両方のユースケースの引数を見ることができます-ダウンストリームのコードがデータを含むセットを期待している場合、例外は素晴らしいです。一方、もしこれが期待されるなら、単に空のセットは素晴らしいです。

これがエラーであるか、許容できる結果であるかどうかは、発信者の期待にかかっていると思うので、選択を発信者に転送します。おそらくオプションを導入しますか？

.CombinationsOf(4, CombinationsGenerationMode.Distinct, Options.AllowEmptySets)

明らかな答えがないかどうかを判断するには、2つのアプローチがあります。

• 最初に1つのオプション、次に他のオプションを想定してコードを記述します。どちらが実際に最もよく機能するかを検討してください。

• 「厳密な」ブール値パラメーターを追加して、パラメーターを厳密に検証するかどうかを示します。たとえば、JavaにSimpleDateFormatはsetLenient、形式と完全に一致しない入力の解析を試みるメソッドがあります。もちろん、デフォルトが何であるかを決める必要があります。

独自の分析に基づいて、空のセットを返すことは明らかに正しいようです。ユーザーが実際に望んでいるものであると特定し、ユーザーがそれを使用することを想像できないため、使用を禁止するというintoに陥っていませんそのように。

一部のユーザーが空でない返品を強制したい場合は、全員に強制するのではなく、その動作を要求する方法を提供してください。たとえば、次のことができます。

• ユーザーのアクションを実行しているオブジェクトの構成オプションにします。
• ユーザーがオプションで関数に渡すことができるフラグにします。
• AssertNonemptyチェーンに入れることができるチェックを提供します。
• 2つの関数を作成します。1つは空でないことをアサートし、もう1つはそうではありません。

それは、ユーザーが何を期待しているのかに本当に依存しています。（やや無関係な）コードで除算を実行する場合、例外を返すInfかNaN、リターンするか、ゼロで除算する場合があります。ただし、どちらも正しいことも間違っていることもありません。

• InfPythonライブラリに戻ると、人々はエラーを隠すためにあなたを攻撃します
• Matlabライブラリでエラーが発生すると、欠損値のあるデータの処理に失敗したために人々があなたを攻撃します

あなたの場合、私はエンドユーザーにとって最も驚くべきソリューションを選びます。セットを扱うライブラリを開発しているので、空のセットはユーザーが扱うことを期待しているように見えるので、それを返すことは賢明なことのように聞こえます。しかし、私は間違っているかもしれません：あなたはここで他の誰よりもコンテキストをはるかによく理解しているので、ユーザーが常に空ではないセットに依存することを期待する場合は、すぐに例外をスローする必要があります。

ユーザーが選択できるソリューション（「厳格な」パラメーターの追加など）は、元の質問を新しい同等の質問「どの値をstrictデフォルトにするか」に置き換えるため、決定的なものではありません。

セット上で要素を選択すると、要素が見つからないため、空のセットを取得することが一般的な概念です（数学）。もちろん、この方法を使用する場合は、数学と一貫している必要があります。

一般的なセットルール：

• Set.Foreach（述語）; //空のセットに対して常にtrueを返します
• Set.Exists（述語）; //空のセットに対しては常にfalseを返します

あなたの質問は非常に微妙です：

• それはあなたの関数の入力が持っている可能性が尊重する契約を：その場合は、無効な入力機能は、通常のパラメータの下で動作していない、それはそれだ、例外を発生させなければなりません。

• 関数の入力はsetとまったく同じように動作する必要があるため、空のsetを返すことができるはずです。

今、私があなたの中にいたら、私は「セット」の方法に行きますが、大きな「しかし」で。

「仮説による」女子学生のみが含まれるコレクションがあるとします。

class FemaleClass{

    FemaleStudent GetAnyFemale(){
        var femaleSet= mySet.Select( x=> x.IsFemale());
        if(femaleSet.IsEmpty())
            throw new Exception("No female students");
        else
            return femaleSet.Any();
    }
}

これで、あなたのコレクションは「純粋なセット」ではなくなりました。なぜならあなたはその上で契約を結んでいるからです。したがって、例外を除いて契約を実施すべきです。

「セット」関数を純粋な方法で使用する場合、空のセットの場合に例外をスローするべきではありませんが、「純粋なセット」ではないコレクションがある場合は、適切な場所で例外をスローする必要があります。

より自然で一貫性のあることを常に行う必要があります。私にとっては、セットはセットルールに従う必要がありますが、セットではないものには適切に考えられたルールが必要です。

あなたの場合、それは良いアイデアのようです：

List SomeMethod( Set someInputSet){
    var result = someInputSet
        .CombinationsOf(4, CombinationsGenerationMode.Distinct)
        .Select(combo => /* do some operation to a combination */)
        .ToList();

    // the only information here is that set is empty => there are no combinations

    // BEWARE! if 0 here it may be invalid input, but also a empty set
    if(result.Count == 0)  //Add: "&&someInputSet.NotEmpty()"

    // we go a step further, our API require combinations, so
    // this method cannot satisfy the API request, then we throw.
         throw new Exception("you requsted impossible combinations");

    return result;
}

しかし、これは本当に良い考えではありません。実行時にランダムに発生する可能性のある無効な状態になりましたが、それは問題に含まれているため、削除できません。例外をユーティリティメソッド内に移動できることを確認してください（同じコードを別の場所に移動します）が、それは間違っており、基本的にあなたができる最善のことは、通常のセット規則に固執することです。

実際には、linqクエリメソッドを書くことができることを示すために新しい複雑さを追加することはあなたの問題には価値がないようです、OPがドメインについてもっと教えてくれるなら、おそらく例外が本当に必要な場所を見つけることができると確信していますまったく問題が例外をまったく必要としない可能性があります）。