Полезность System.Diagnostics. Контракты, о которых идет речь
Я играл с новым классом System.Diagnostics.Contracts, потому что сначала он казался очень полезным. Статические методы для проверки входящих аргументов, возвращаемых значений и т. Д. Это был чистый интерфейс, который мог заменить множество операторов if-then и встроенных библиотечных инструментов.
Однако в большинстве ситуаций во время выполнения он кажется менее чем полезным. Из того, что я могу сказать, это не выдает ошибку, поэтому я не могу поймать что-либо, чтобы узнать, провалился ли контракт. Появляется диалоговое окно с ошибкой. Если я запускаю службу wcf на удаленной машине, на которую редко смотрят люди ... откуда мне знать, что контракт провалился? Если я не могу уловить тот факт, что произошла ошибка, как я мог сообщить вызывающему абоненту службы о том, что он выпал?
Throw-Catch существует уже некоторое время, я не понимаю, почему контракты хотят обойти это. Я пытаюсь использовать эту вещь неправильно? Если это так, то кто-то дает мне реальную ситуацию, в которой имеет смысл контракт на выполнение. Кен
1 ответ
Насколько я могу судить, это не вызывает ошибки, поэтому я ничего не могу уловить, чтобы узнать, не удалось ли выполнить контракт.
Если вам нужно сгенерировать определенное исключение для вызова кода для перехвата, тогда вы должны использовать методы Contract.Requires или устаревшие if-then-throws, за которыми следует Contract.EndContractBlock () . Вы бы сделали это, когда другой код уже ожидает и зависит, например, от регулярных генерируемых исключений.
См. раздел 5.1: Проверка аргументов и контракты руководства пользователя для полного объяснения того, когда использовать различные формы предусловия.
Выскакивает диалоговое окно с ошибкой.
Если вы уберете отметку «Утверждать при сбое контракта» на вкладке «Контракты кода» в настройках вашего проекта, вы получите фактическое исключение, выбрасываемое в проблемной точке кода во время отладки, а не диалоговое окно. Однако это не для ловли.
Throw-Catch существует уже некоторое время, я не понимаю, почему контракты хотят обойти это. Я пытаюсь неправильно использовать эту штуку? Если так, то кто-нибудь представит мне реальную ситуацию, в которой контракт времени выполнения имеет смысл.
Раздел 7.5: Rational for Runtime Behavior и Раздел 7.6: ContractException руководства пользователя объясняет, почему он работает таким образом.
Идея состоит в том, что вам никогда не нужно писать программы, содержащие особую логику, обрабатывающую нарушения контрактов. Они никогда не должны происходить в правильных программах и указывать на серьезную ошибку в коде, которую необходимо исправить.Это похоже на то, как следует избегать перехвата ArgumentNullException .
Вы все равно должны генерировать регулярные исключения в исключительных случаях, когда не указывают на ошибки в самом коде, например, когда файлы не могут быть найдены. Это позволяет вызывающему коду обрабатывать это обстоятельство соответствующим образом.
Если я запускаю службу wcf на удаленном компьютере, на который редко обращает внимание человек ... как я узнаю, что контракт провалился?
Желательно, чтобы вы как можно больше тестировали программное обеспечение, прежде чем использовать его, чтобы убедиться, что он никогда не нарушает никаких контрактов.
Если у вас есть особая потребность переопределить поведение среды выполнения, вы можете сделать это, написав свой собственный класс среды выполнения контракта. См. Раздел 7.7: Предоставление настраиваемого класса выполнения контракта в руководстве пользователя для получения дополнительной информации.
Редактировать: В ответ на комментарий ниже ...
Вы говорите, что это предназначено для поиска ошибок в коде, но большинство ошибок в коде происходит из-за данных, переданных из внешних источников, а не из-за ошибки кода. И программное обеспечение должно как регистрировать факт передачи некорректных данных, так и сообщать им, что они передали неверные данные, чтобы они могли это исправить.
Предварительные условия - это контракты, которые определяют, когда метод разрешен для вызова, и предназначены для проверки вызывающей стороной во время вызова метода. Средство проверки времени выполнения внедрит соответствующие проверки в вызывающий код, а не в сам метод.Если у вас есть доступная статическая проверка, она будет указывать вам всякий раз, когда вы не сможете обеспечить предварительные условия перед вызовом этого метода.
В вашей ситуации ваши внутренние методы обработки данных должны определять предварительные условия, указывающие, какие данные они разрешают. Когда данные передаются из внешних источников, которыми вы не можете управлять, вы должны проверить их и обработать обычным способом; вы не хотите использовать для этого кодовые контракты. Однако, если, например, вы забудете полностью проверить эти данные, вы столкнетесь с нарушением контракта при вызове внутреннего кода с предварительными условиями. Это указывает на ошибку в вашем собственном коде .