Плюсы и минусы различных методов тестирования предварительных условий?

Я предполагаю, что к интерфейсу IHttpHandler применяется контракт. .ProcessRequest, для которого требуется этот контекст != null. Контракты интерфейса наследуются их реализаторами, поэтому вам не нужно повторять Requires. На самом деле вам не разрешено добавлять дополнительные операторы Requires, поскольку вы ограничены требованиями, связанными с контрактом интерфейса.

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

Тем не менее, если вы работаете в среде, где вы активно используете контракты кода и статический анализ, то определенно предпочтительнее помещать утверждения в форму контракта, чтобы воспользоваться преимуществами статического анализа. Даже если вы не используете статический анализ, вы все равно можете оставить дверь открытой для более поздних преимуществ, используя контракты. Главное, на что следует обратить внимание, — это настроить свои проекты для выполнения перезаписи, иначе контракты не приведут к исключениям во время выполнения, как можно было бы ожидать.

Чтобы уточнить, что сказали комментаторы, разница между Assert, Assume и Requires заключается в следующем:

• Выражение Contract.Assert преобразуется в утверждение переписателем контракта, и статический анализатор пытается доказать выражение на основе его существующих свидетельств. Если это не может быть доказано, вы получите предупреждение статического анализа.
• Выражение Contract.Assume игнорируется переписателем контракта (насколько мне известно), но интерпретируется статическим анализатором как новое доказательство, которое он может принять во внимание в своем статическом анализе. Contract.Assume используется для «заполнения пробелов» в статическом анализе либо там, где ему не хватает сложности, чтобы сделать необходимые выводы, либо при взаимодействии с кодом, который не был украшен контрактами, так что вы можете, например, предположить , что конкретный вызов функции возвращает ненулевой результат.
• Contract.Requires — это условия, которые всегда должны быть истинными при вызове вашего метода. Они могут быть ограничениями параметров метода (что является наиболее типичным), а также ограничениями общедоступных состояний объекта (например, вы можете разрешить вызов метода только в том случае, если Initialized имеет значение True). ограничений побуждают пользователей вашего класса либо проверять Initialized при использовании объекта (и, предположительно, обрабатывать ошибку соответствующим образом, если это не так), либо создавать свои собственные ограничения и/или инварианты класса, чтобы уточнить, что Initialization действительно произошла.

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

Я бы сказал, что 2-я и 3-я версии похожи тем, что они никак не решают проблему.

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