.Net, эквивалентный Java AssertionError

Question

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

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

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

Answer 1

Обычно я бы выбрал InvalidOperationException или ArgumentOutOfRangeException в зависимости от того, откуда взялось это значение.

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

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

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

Answer 2

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

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

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