24

メソッドがコレクション (いくつかの構成文字列を含むリストなど) を取得し、何らかの方法でそれを調べようとする単純な例を考えてみます。

void Init()
{
    XmlDocument config = new XmlDocument();
    config.Load(someXml);
    var list = config.SelectNodes("/root/strings/key"); // Normally, list should not be null or empty

    if (list == null || list.Count == 0)
        throw new SomeExceptionType(message);   // What kind of exception to throw?

    // Iterate list and process/examine its elements
    foreach (var e in list) ...
}

この特定のインスタンスでは、何も取得されない場合、メソッドは正常に続行できません。このような状況でスローする例外の種類がわかりません。私の知る限り、私のオプションは次のとおりです。

  • 手動で何もスローせNullReferenceExceptionず、自動的にスローされるようにします (空のリストの状況を処理しません)。

  • カスタム例外タイプをスローします (おそらく、呼び出し元が例外について何かをしようとは思わないため、良い考えではありません。つまり、呼び出し元は、処理する特定の例外タイプを探しているわけではありません)。

  • 何か他のことをしますか？
4

4 に答える 4

2

この場合、エレガントにスローできる単一の組み込み例外があるかどうかはわかりません...NullReferenceException空のリストはnull参照ではないため、aは不適切です

呼び出し元はtry...catch(Exception)、例外が実際にSuperDooperListNullOrEmptyFunTimeException

これは呼び出し元の観点からは回復不能なエラー (つまり、選択された Xml パスを制御できず、読み込まれている XML を制御できない) であるため、例外はログにダンプされるだけです。または、人間が消費するために画面上に表示されます。その時点では、実際のメッセージはタイプよりも重要であるため、意味がありません。

一方、回復可能な場合 (呼び出し元は、ロードする xml に正しい形式の xml が含まれていることを確認した後でメソッドを再試行できます。または、呼び出し元はユーザーに通知して、XML と "今すぐ再試行しますか?" のようなもの) 次に、型指定された例外を提供する必要があります。これにより、他の何かがひどく間違っていることを意味する単純な古い例外とは対照的に、再試行しても安全であることがわかります。再試行すると事態が悪化するだけです。 ...

于 2013-09-05T15:01:43.013 に答える
0

設計上の問題であるため、プログラミングの問題はそれほど多くありません.NETリストオブジェクトが空のときに例外をスローしない理由は、空のリストが予想され、許容される状況であることが多いためです。

コンテキスト内で、使用するリストが空になることが想定されていない場合は、例外 (カスタムのもの) をスローします。

ただし、リストが空である可能性があり論理的である場合、なぜ全体を中断する必要があるのですか?それは例外ではなく例外なので、例外が必要ですか? ループと空のforeachリストは例外をスローしません。ループは単純にループしません。

null の可能性については (よく理解している場合は非常にまれですSelectNodes)、同じ問題です。一部のライブラリまたは関数でnullは、 a を返すことは例外ではなく通常の動作です。

于 2013-09-05T13:55:42.067 に答える