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

Question

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

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

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

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

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

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