Стоит ли включать проверку исполнения кода контрактов для .NET 4.0 во время сборки выпуска? - PullRequest
9 голосов
/ 29 ноября 2011

Предполагая, что все новые. NET 4.0 код

Я вижу, что есть возможность включить их.Однако я не понимаю, что такое лучшая практика?

Является ли наилучшей практикой, когда после статической проверки вам действительно не нужно выполнять проверку во время выполнения (так как компилятор проверяет соблюдение условий)?Или есть сценарии, в которых, хотя компилятор проверяет его для вас, все же возможно, что во время выполнения условие не будет выполнено?

Любые хорошие онлайн-обсуждения или статьи по этому вопросу.Я вижу многих, которые объясняют, как это сделать, но не многих, которые объясняют, что является наилучшей практикой, предполагая, что весь новый код .NET 4.0 без необходимости обратной совместимости.

Ответы [ 2 ]

5 голосов
/ 29 ноября 2011

так как компилятор обеспечивает выполнение условий?

Очень редко статический верификатор сможет проверить все приложение. Мы обычно соглашаемся на основные части.

Стоит ли включать проверку исполнения кода для .NET 4.0 во время сборки выпуска?

Вероятно, не вариант Full , а один из более легких, например Только предварительные условия .

Для кода, критичного к производительности, вы можете полностью их отключить.

4 голосов
/ 01 декабря 2011

Зависит от того, как вы используете. Требуется.

Если вы используете режим «Требуется специальный контракт»:

public void SomeMethod(SomeClass x)
{
  if (x == null) throw new ArgumentNullException("x");
  Contract.EndContractBlock();

  ...
}

Вы можете безопасно отключить проверки во время выполнения и сохранить проверки ошибок и исключения

Если вы используете режим «Требуется стандартный контракт»:

public void SomeMethod(SomeClass x)
{
  Contract.Requires<ArgumentNullException>(x != null);

  ...
}

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

Я бы не стал использовать более высокие уровни проверки по очень простой причине: если какой-либо контракт, кроме Contract.Requires<E>, потерпит неудачу, среда выполнения выдаст System.Diagnostics.ContractException, что, вероятно, не понравится пользователям.

Кстати, Хенк Холтерман абсолютно прав, что статический верификатор ограничен, и вы не должны полностью на него полагаться.

...