.Net эквивалентно Java AssertionError

Question

В Java я иногда выбрасываю AssertionError напрямую, чтобы утверждать, что определенная строка не будет достигнута. Примером этого может быть утверждение о том, что регистр default в операторе switch не может быть достигнут (см. эту страницу JavaSpecialists для примера).

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

Редактировать - Чтобы уточнить, я ищу механизм для обозначения сбоев во время выполнения, в выпущенном коде, чтобы указать, что произошел (возможно катастрофический) сбой какого-либо инварианта в коде. В связанном примере генерируется случайное целое число в диапазоне от 0 до 2 (включительно) и утверждается, что сгенерированное число всегда равно 0, 1 или 2. Если это утверждение не выполняется, было бы лучше полностью остановить выполнение, а не продолжать с неизвестным повреждено состояние системы.

Answer 1

Я бы обычно выбрасывал InvalidOperationException или ArgumentOutOfRangeException в зависимости от того, откуда пришло значение.

В качестве альтернативы есть Debug.Assert (который завершится ошибкой только тогда, когда вы определили символ препроцессора DEBUG) или в .NET 4.0 вы можете использовать Contract.Fail, Contract.Assert или Contract.Assume в зависимости от ситуации. Явное создание исключения имеет то преимущество, что компилятор знает, что следующий оператор недостижим.

Я не большой поклонник Debug.Assert - он обычно не подходит для релиза (так как он выдает окно подтверждения, а не просто проваливается) и по умолчанию он не будет запускаться при выпуске в любом случае. Я предпочитаю исключения, которые всегда генерируются, поскольку они препятствуют выполнению вашего кода независимо от возможности обнаружить, что «что-то не так».

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

Answer 2

Вы можете использовать метод Trace.Assert, который будет работать в сборках выпуска (если у вас определен символ компиляции TRACE, который определен по умолчанию в проектах Visual Studio). Вы также можете настроить способ реагирования вашего приложения на ошибки утверждения с помощью TraceListener. По умолчанию (неудивительно) DefaultTraceListener, который будет отображать утверждение в диалоговом окне, если приложение работает в интерактивном режиме. Например, если вы хотите создать исключение, вы можете создать свой собственный TraceListener и добавить его к методу Fail. Затем вы можете удалить DefaultTraceListener и использовать свой собственный, либо программно , либо в файле конфигурации .

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

Для .NET 4.0 я бы определенно взглянул на метод Contract.Assert. Но этот метод компилируется только тогда, когда определены символы DEBUG или CONTRACTS_FULL. DEBUG не будет работать с релизными сборками, а CONTRACTS_FULL также включит все остальные проверки контрактов, некоторые из которых вы, возможно, не захотите присутствовать в релизных сборках.