.NET, эквивалентный AssertionError Java
Donald Norman, 'Дизайн Повседневных Вещей'
Не о программировании, по сути, а о том, как вещи в мире должны работа - вид психологии удобства использования.
Это было неоценимо для меня в разработке и интерфейсы конечного пользователя и API.
2 ответа
Обычно я выбрасываю InvalidOperationException или ArgumentOutOfRangeException в зависимости от того, откуда взялось значение.
В качестве альтернативы есть Debug.Assert (что не сработает, только если у вас определен символ препроцессора DEBUG) или в .NET 4.0 вы можете использовать Contract.Fail , Contract.Assert или Contract.Assume в зависимости от ситуации. Явное генерирование исключения имеет то преимущество, что компилятор знает, что следующий оператор недоступен.
Я не большой поклонник Debug.Assert - обычно он не подходит для выпуска (поскольку он выдает вверх окно утверждения, а не просто сбой), и по умолчанию он все равно не будет запускаться в выпуске. Я предпочитаю исключения, которые всегда генерируются, так как они не позволяют вашему коду продолжать работу независимо от возможности обнаружить, что «что-то не так».
Контракты кода несколько меняют игру, поскольку есть всевозможные варианты того, что сохраняется во время выполнения, и статическая проверка может помочь доказать, что вы не попадете в это состояние. Однако вам все равно нужно выбрать политику времени выполнения ...
Вы можете использовать метод Trace.Assert , который будет работать на сборках выпуска (если у вас есть TRACE ] определен символ компиляции, который определен по умолчанию в проектах Visual Studio). Вы также можете настроить способ реакции вашего приложения на ошибки утверждения с помощью TraceListener . По умолчанию (неудивительно) используется DefaultTraceListener , который покажет утверждение в диалоговом окне, если приложение работает в интерактивном режиме. Например, если вы хотите вызвать исключение, вы можете создать свой собственный TraceListener и передать его методу Fail . Затем вы можете удалить DefaultTraceListener и использовать свой собственный, либо программно , либо в файле конфигурации .
Это похоже на множество проблем и оправдано только в том случае, если вы хотите динамически изменять способ обработки утверждений вашим приложением посредством прослушивателей трассировки. Для нарушений, которые вы всегда хотите потерпеть неудачей, создайте свой собственный класс AssertionException и сразу же выбросьте его.
Для .NET 4.0 я бы определенно посмотрел на метод Contract.Assert . Но этот метод компилируется только тогда, когда определены символы DEBUG или CONTRACTS_FULL . DEBUG не будет работать в сборках выпуска, а CONTRACTS_FULL также включит проверку всех других контрактов, некоторые из которых вы, возможно, не захотите использовать в сборках выпуска.