予期しない列挙型の値を処理するための好ましい方法は何ですか？

Question

列挙型の値を受け入れるメソッドがあるとします。このメソッドは、値が有効であることを確認した後、可能な値を超えてswitchとなります。だから質問は、予期しない値を扱う好ましい方法は何かの後に値の範囲が検証されていますか？例えば

：

enum Mood { Happy, Sad } 

public void PrintMood(Mood mood) 
{ 
    if (!Enum.IsDefined(typeof(Mood), mood)) 
    { 
     throw new ArgumentOutOfRangeException("mood"); 
    } 

    switch (mood) 
    { 
     case Happy: Console.WriteLine("I am happy"); break; 
     case Sad: Console.WriteLine("I am sad"); break; 
     default: // what should we do here? 
    } 

defaultケースを処理する好ましい方法は何ですか？

• 私が好む私は

Answer 1

と考えていないいくつかの他の方法

throw new NotImplementedException()（またはその他の例外）// can never happen

Debug.Fail()（またはDebug.Assert(false)）のようなコメントを残しますthrow new NotImplementedException("Unhandled Mood: " + mood)。重要なのは、列挙が将来変更される可能性があり、この方法はそれに応じて更新されない可能性があることです。例外を投げるのが最も安全な方法です。

メソッドがライブラリの一部であり、新しい値がデバッグモードでテストされない可能性があるので、Debug.Fail()メソッドが嫌いです。そのライブラリを使用している他のアプリケーションは、そのような場合には奇妙なランタイム動作に直面する可能性がありますが、例外をスローするとエラーがすぐに判明します。

注：にはNotImplementedExceptionが存在します。

Answer 2

デフォルトでは、渡された列挙型の値を呼び出すトレースを持つことができます。例外をスローするのは問題ありませんが、大規模なアプリケーションでは、コードが列挙型の他の値を気にしない場所がいくつかあります。
したがって、コードが列挙型の可能な値をすべて処理する予定の場合は、後で戻って例外を削除する必要があります。 Javaでは

Answer 3

、標準的な方法は、2つの理由のために、AssertionErrorをスローすることです：

1. これはassertsが無効になっている場合でも、エラーがスローされることを保証します。
2. 他の列挙型の値がないと主張しているので、AssertionErrorは、NotImplementedException（Javaにはありません）よりも前提条件を文書化しています。私のコードベースではほとんどすべてのswitchステートメントの

Answer 4

、私はこの方法は、エラーが検出された時点で、列挙型の値を詳述例外がスローされます、次のデフォルトの場合

switch(value) { 
... 
default: 
    Contract.InvalidEnumValue(value); 
} 

を持っています。

public static void InvalidEnumValue<T>(T value) where T: struct 
{ 
    ThrowIfFalse(typeof(T).IsEnum, "Expected an enum type"); 
    Violation("Invalid Enum value of Type {0} : {1}", new object[] { typeof(T).Name, value }); 
} 

Answer 5

は、意見や好み、それを呼び出しますが、列挙型の背後にある考え方は、それが可能な値の完全なリストを表していることです。コードで "予期しない値"が渡されている場合、列挙型（または列挙型の目的）は最新ではありません。私の個人的な好みは、すべての列挙型がUndefinedのデフォルト割り当てを持つことです。列挙型が定義済みのリストであることを考えると、それはあなたの消費するコードで古くなるべきではありません。

あなたの関数が私の場合に予期しない値またはUndefinedを取得した場合の対処方法については、一般的な回答は不可能ではないようです。私にとっては、enum値を評価する理由のコンテキストに依存します。コード実行を停止する必要があるか、デフォルト値を使用できるかどうかです。

Answer 6

私の意見は、プログラマのエラーであるため、あなたはそれをアサートするか、RuntimException（Java、または他の言語に相当するものであれ）を投げてください。私はこれに使用するRuntimeExceptionから拡張された独自のUnhandledEnumExceptionを持っています。

Answer 7

有効な入力を提供することは呼び出し元関数の責任であり、暗黙的にenumにないものは無効です（実用的なプログラマはこれを暗に意味すると思われます）。つまり、これは、enumを変更するたびに、それを入力として受け入れるすべてのコード（および出力として出力するコード）を変更する必要があることを意味します。とにかくそれはおそらく本当です。頻繁に変更されるenumがある場合は、enumが通常はコンパイル時のエンティティであることを考慮して、enum以外のものを使用しているはずです。

Answer 8

正確なプログラム応答はとなり、開発者は問題を容易に見つけ出すことができます。 mmyersとJaredParはどちらも良い方法でした。

なぜ死ぬのですか？それはとても極端なようです！

あなたはを通じて適切かつちょうど秋列挙型の値を処理していない場合、あなたが予期しない状態にあなたのプログラムを入れていることであることの理由。いったん予期しない状態になったら、何が起こっているのかを知っている人。これは、悪いデータ、追跡が困難なエラー、またはセキュリティ上の脆弱性につながる可能性があります。

また、プログラムが終了すると、QAでそれをキャッチしようとする可能性がさらに高くなります。

Answer 9

私は普通（0）未定義の値を定義しよう：

enum Mood { Undefined = 0, Happy, Sad } 

その方法は、私がいつも言うことができる：私は通常これを行う方法を

switch (mood) 
{ 
    case Happy: Console.WriteLine("I am happy"); break; 
    case Sad: Console.WriteLine("I am sad"); break; 
    case Undefined: // handle undefined case 
    default: // at this point it is obvious that there is an unknown problem 
      // -> throw -> die :-) 
} 

これは、少なくともです。

Answer 10

これはテスト駆動開発がなぜ重要かを証明する質問の1つです。

この場合、文字通り値が処理されていないためサポートされていないため、NotSupportedExceptionに行きます。

呼び出しコードでは、このような状況を処理できる必要があり、ユニットテストを作成してこのような状況を簡単にテストできます。

Answer 11

C＃の場合、知る価値のあるものはEnum.IsDefined() is dangerousです。あなたはあなたのようにそれに頼ることはできません。例外をスローして大声で死に至るのは、期待された値ではないものを得ることです。

enumが整数ではないので、enumは整数ではないので、（enumが更新されずにswitch文が使用されていない限り）予期しない値を得ることができないため、Javaのenum 。あなたはまた、ヌル値に対応しなければなりません。しかし、あなたが認識していないnull以外の場合を得ることは例外をスローするための良いケースです。

Answer 12

私は上記の回答のほとんどが有効だと思いますが、私は正しいとは確信していません。

正しい答えはあなたが非常にまれOO言語に切り替えていない、である、それはあなたがオブジェクト指向間違っをしているを示しています。この場合、Enumクラスに問題があることを示す完全な指標です。

あなただけConsole.WriteLineを（mood.moodMessageを（））を呼び出すと、状態のそれぞれについてmoodMessageを定義する必要があります。新しい状態が追加された場合

- すべてのあなたのコードは自動的に適応させるべきで、何も、失敗しない例外をスローしたり、変更を必要とする必要があります。

編集：コメントへの応答。あなたの例では

は、「グッドOO」にFileModeオブジェクトによって制御されるファイルモードの機能があることを。これは、FileModeごとに異なる "オープン、リード、ライト..."操作を持つデリゲートオブジェクトを含むことができるので、File.open（ "name"、FileMode.Create）は次のように実装できます。 API）：

open(String name, FileMode mode) { 
    // May throw an exception if, for instance, mode is Open and file doesn't exist 
    // May also create the file depending on Mode 
    FileHandle fh = mode.getHandle(name); 
    ... code to actually open fh here... 
    // Let Truncate and append do their special handling 
    mode.setPosition(fh); 
} 

これは、スイッチでそれをやろうとしているよりもはるかに滑らかな印象です...（ちなみに、この方法は、パッケージプライベートとおそらく「モード」のクラスに委譲両方だろう）

OOがうまくいったら、すべての単一のメソッドは、数行の本当に分かりやすい単純なコード（TOO simple）のように見えます。私は答えを投稿しています