Каков предпочтительный метод обработки неожиданных значений перечислимого типа?

Question

Предположим, что у нас есть метод, который принимает значение перечисления. После того, как этот метод проверяет, что значение действительно, оно switch es над возможными значениями. Итак, вопрос в том, какой предпочтительный метод обработки неожиданных значений после диапазон значений подтвержден?

Например:

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 случая?

• Оставить комментарий как // can never happen
• Debug.Fail() (или Debug.Assert(false))
• throw new NotImplementedException() (или любое другое исключение)
• Некоторые другие так, как я не думал о

Answer 1

Я предпочитаю throw new NotImplementedException("Unhandled Mood: " + mood). Дело в том, что перечисление может измениться в будущем, и этот метод не может быть соответствующим образом обновлен. Выбрасывание исключения, по-видимому, является самым безопасным методом.

Мне не нравится метод Debug.Fail(), потому что этот метод может быть частью библиотеки, а новые значения могут не тестироваться в режиме отладки. В этом случае другие приложения, использующие эту библиотеку, могут столкнуться с странным поведением в режиме исполнения, в то время как в случае выброса исключения ошибка будет немедленно известна.

Примечание: NotImplementedException есть в commons.lang.

Answer 2

У вас может быть трассировка по умолчанию, вызывающая значение переданного перечисления. Выбрасывание исключений - это нормально, но в большом приложении будет несколько мест, где ваш код не заботится о других значениях перечисления.
Итак, если вы не уверены, что код намеревается обрабатывать все возможные значения перечисления, вам придется вернуться позже и удалить исключение.

Answer 3

В Java, стандартный способ, чтобы бросаться AssertionError, по двум причинам:

1. Это гарантирует, что даже если asserts отключены, выдается ошибка.
2. Вы утверждаете, что других значений перечисления нет, поэтому AssertionError документирует ваши предположения лучше, чем NotImplementedException (что Java не имеет в любом случае).

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.Учитывая, что перечисление является определенным списком, оно никогда не должно быть устаревшим с вашим кодом потребления.

Что касается того, что делать, если ваша функция получает либо неожиданное значение, либо неопределенное в моем случае, общий ответ кажется невозможным. Для меня это зависит от контекста причины оценки значения перечисления: является ли ситуация, когда выполнение кода должно прекратиться или может использоваться значение по умолчанию?

Answer 6

Мое мнение таково, что, поскольку это ошибка программиста, вы должны либо заявить об этом, либо выбросить RuntimException (Java или что-то еще, что эквивалентно для других языков). У меня есть собственное UnhandledEnumException, которое распространяется на RuntimeException, которое я использую для этого.

Answer 7

Ответственность за предоставление действительного ввода и неявное выполнение функций, не относящихся к перечислению, не является обязательным (программный программист подразумевает это). Тем не менее, это означает, что в любое время, когда вы меняете свой список, вы должны изменить ВСЕ код, который принимает его как вход (и код SOME, который дает его как вывод). Но это, вероятно, так или иначе. Если у вас есть перечисление, которое часто изменяется, вы, вероятно, должны использовать что-то иное, кроме перечисления, считая, что перечисления обычно являются объектами компиляции.

Answer 8

Правильный ответ программы будет die таким образом, чтобы разработчик мог легко выявить проблему. 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

Это один из тех вопросов, который доказывает, почему развитие, основанное на испытаниях, так важно.

В этом случае я бы выбрал исключение NotSupportedException, потому что буквально значение было необработанным и, следовательно, не поддерживалось. A NotImplementedException дает больше идеи: «Это еще не закончено»;)

Код вызова должен иметь возможность обрабатывать подобную ситуацию, и модульные тесты могут быть созданы для простой проверки таких ситуаций.

Answer 11

Для C# что-то стоит знать, это Enum.IsDefined() is dangerous. Вы не можете полагаться на него так, как есть. Получение чего-то не от ожидаемых значений является хорошим примером для того, чтобы выбросить исключение и умереть громко.

В Java это отличается от того, что перечисления являются не целочисленными классами, поэтому вы действительно не можете получить неожиданные значения (если обновление не обновлено, а ваш оператор switch не является), что является одной большой причиной, почему я предпочитаю перечисления Java ,Вы также должны обслуживать нулевые значения. Но получение ненулевого случая, которое вы не распознаете, является хорошим примером для исключения исключения.

Answer 12

Я полагаю, что большинство из приведенных выше ответов действительно, но я не уверен, что они верны.

Правильный ответ: вы очень редко переключаетесь на язык OO, это указывает на то, что вы неправильно выполняете OO. В этом случае это прекрасный признак того, что ваш класс Enum имеет проблемы.

Вы должны просто называть Console.WriteLine (mood.moodMessage()) и определять moodMessage для каждого из состояний.

Если добавлено новое состояние - весь ваш код должен автоматически адаптироваться, ничто не должно терпеть неудачу, вызывать исключения или изменения.

Редактировать: Ответить на комментарий.

В вашем примере, чтобы быть «хорошим OO», функциональность файлового режима будет контролироваться объектом FileMode. Он может содержать объект-делегат с операциями «open, read, write ...», которые отличаются для каждого FileMode, поэтому File.open («name», FileMode.Create) может быть реализован как (извините за отсутствие знакомства с АНИ):

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 просто. У вас всегда возникает ощущение, что есть какое-то большое грязное «Сырное ядро», держащее вместе все маленькие объекты nacho, но вы его никогда не найдете - это начо все время вниз ...