Полезность системы. Диагностика. Контракты в вопросе

Я играл с новым классом System.Diagnostics.Contracts, потому что сначала он казался очень полезным. Статические методы проверки входящих аргументов, возвращаемые значения и т.д. Это был чистый интерфейс и мог заменить множество инструкций if-then и встроенных библиотечных инструментов.

Однако он кажется менее полезным в большинстве ситуаций времени исполнения. Из того, что я могу сказать, это не вызывает ошибку, поэтому я не могу поймать ничего, чтобы узнать, не закончился ли контракт. Появится диалоговое окно с ошибкой. Если я запускаю службу wcf на удаленном ящике, на котором редко бывают люди, посмотрим на это... как я узнаю, что контракт не прошел? Если я не могу уловить тот факт, что произошла ошибка, как я могу позволить вызывающему абоненту узнать, что они работают?

Throw-Catch уже давно существует, я не понимаю, почему Контракты хотят обойти это. Я пытаюсь использовать эту вещь неправильно? Если это так, то кто-то дает мне реальную ситуацию, когда соглашение о сроках исполнения имеет смысл. Кен

Ответ 1

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

Если вам нужно бросить конкретное исключение для вызова кода для catch, тогда вы должны использовать методы Contract.Requires<TException> или устаревшие if-then-throws, за которыми следует Contract.EndContractBlock(). Вы сделали бы это, когда другой код уже ожидает и зависит от обычных исключений, например, брошенных.

См. раздел 5.1 "Проверка и заключение аргументов" руководства пользователя для полного объяснения того, когда использовать различные формы предварительного условия.

Появится диалоговое окно с ошибкой.

Если вы отклоняете "Assert on Contract Failure" на вкладке "Контрактные контракты" ваших настроек проекта, вы получите фактическое исключение, заброшенное в оскорбительной точке кода во время отладки, а не в диалоговом окне. Однако это не для ловли.

Throw-Catch уже давно существует, я не понимаю, почему Контракты хотят обойти это. Я пытаюсь использовать эту вещь неправильно? Если да, то кто-то дает мне реальную ситуацию, когда имеет смысл контракт на выполнение.

Раздел 7.5: Рациональное поведение Runtime и раздел 7.6: ContractException руководства пользователя объясняет, почему он работает таким образом.

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

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

Если я запускаю службу wcf в удаленном ящике, на котором редко кто-то смотрит на человека... Как я могу узнать, что контракт не прошел?

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

Если вам необходимо переопределить поведение во время выполнения, вы можете сделать это, написав собственный класс выполнения контракта. См. Раздел 7.7. Дополнительную информацию см. В разделе 7.7: Предоставление класса Runtime пользовательского контракта руководство пользователя.

Изменить: в ответ на комментарий ниже...

Вы говорите, что он предназначен для обнаружения ошибок в коде, но большинство ошибок в коде исходят из данных, переданных из внешних источников, а не из-за сбоев в кодах. И программное обеспечение необходимо обоим, запишите тот факт, что кто-то передал плохие данные и сказал им, что они прошли в плохих данных, чтобы они могли его исправить.

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

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