Бросок NotImplementedException в случае по умолчанию в операторе switch

Question

Должен ли я бросить NotImplementedException() на default, если у меня есть дела для всех возможных типов перечислений?

Answer 1

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

Но теперь вы должны рассмотреть контекст.

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

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

Важно помнить, что перечисления не проверяются диапазоном в Framework. Я могу указать, что для метода требуется параметр типа Environment.SpecialFolder; но он примет любое 32-разрядное целочисленное значение.

Короче говоря, если ваш метод предназначен для общественного потребления, да, непременно, бросьте. Если это не для общественного потребления, Подтвердите .

Answer 2

Это действительно зависит.

• NotImplementedException - это что-то вроде отметки для меня. Это означает, что кто-то придет позже, чтобы закончить код. Однако я не думаю, что это случай по умолчанию, который не должен происходить.

• Когда вы проверяете состояние объекта, вы можете рассмотреть InvalidOperationException . Ваш метод предназначен только для работы с существующими делами.

• Когда вы различаете входной параметр ArgumentException всегда подходит.

• В других случаях я предпочитаю NotSupportedException . Это немного указывает на то, что что-то не так с платформой или версией. А несовместимые версии кода - истинный корень проблемы, когда произошел случай переключения по умолчанию, который не должен происходить.

Answer 3

Может быть, не NotImplementedException, а ArgumentException. Это будет зависеть от того, где вы его используете.

Answer 4

Звучит как разумный вариант.

Лично я бы создал новый тип исключения (возможно, InvalidEnumException или дал бы ему другое имя, которое будет иметь смысл для группы поддержки) и выбросил бы его.

Answer 5

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

Answer 6

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

Answer 7

Сначала вы должны подумать, что бы это значило, если бы вы получили значение вне известных случаев - что представляет собой включаемая переменная? Тогда вы можете просто использовать тип исключения, который соответствует тому, что на самом деле происходит.

Answer 8

Если вы бросите исключение, что произойдет? В каком контексте выполняется оператор switch? Должна ли такая ситуация случиться? Должно ли это когда-либо происходить во время выполнения в рабочем коде? Охватывают ли ваши юнит-тесты эту ситуацию? Если это так, возможно, лучше утверждать.

Answer 9

Я бы сказал, по крайней мере, вы должны поставить туда Debug.Fail().

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

Answer 10

Это действительно зависит от конкретного процесса, но да, это хороший процесс, чтобы ответить по умолчанию: в случае, если чего-то там не должно было быть.