Утверждения всегда плохо? [закрытый]

20
задан Sam 27 August 2014 в 12:09
поделиться

11 ответов

Мы используем измененную версию, утверждают, согласно комментарию JaredPar, что действия как контракт. Эта версия компилируется в код выпуска, таким образом, существует небольшой размер наверху, но отключенный, если переключатель диагностики не установлен, такой, что производительность наверху минимизирована. Наш утверждать обработчик в этом экземпляре может быть установлен на отключенный, "тихий" режим (например, журнал в файл), или шумный режим (например, дисплей на экране с аварийным прекращением работы / игнорируют, где аварийное прекращение работы выдает исключение).

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

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

20
ответ дан 29 November 2019 в 23:53
поделиться

Это зависит от критичность Вашей системы : утверждения failfast стратегия , в то время как исключения могут использоваться, когда система может выполнить некоторое восстановление.

, Например, я не буду использовать утверждения в банковском приложении или телекоммуникационной системе: я выдал бы исключение, которое будет поймано верхнее в стеке вызовов. Там, ресурсы могут быть убраны, и следующий вызов/транзакция может быть обработан; только один будет потерян.

3
ответ дан 29 November 2019 в 23:53
поделиться

утверждения и исключения используются для двух разных вещей.

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

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

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

5
ответ дан 29 November 2019 в 23:53
поделиться

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

единственное время мы используем утверждения, теперь то, если одно из следующего верно.

  1. код утверждения имеет влияние производительности noticable
  2. , конкретное условие не фатальное
  3. Иногда существует часть кода, который может или не может быть мертвым. Мы добавим утверждение, которое по существу говорит, "как Вы добирались здесь". Не увольнение не означает, что код действительно мертв, но если QA посылает мне по электронной почте и говорит, "что делает это среднее утверждение", у нас теперь есть репродукция для получения до конкретной части кода (это сразу документируется, конечно).
6
ответ дан 29 November 2019 в 23:53
поделиться

Действительно ли это верно, что утверждение существует в отладочной сборке, но не в сборке конечных версий?

, Если Вы хотите проверять/утверждать что-то, разве Вы не хотите делать это в сборке конечных версий, а также в отладочной сборке?

1
ответ дан 29 November 2019 в 23:53
поделиться

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

Мое любимое место для использования их находится в блоках кода, которые действительно не должны быть достигнуты - такой как default случай в switch - оператор по перечислению, которое имеет case для каждого возможного перечисления значений.

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

Предоставленный, в тех местах Вы обычно хотите что-то, что прерывает производственные сборки также. Но принцип abort() луг в таких условиях настоятельно рекомендован. Хорошее отслеживание стека в отладчике дает Вам информацию для исправления ошибки быстрее, чем предположение вокруг.

3
ответ дан 29 November 2019 в 23:53
поделиться

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

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

1
ответ дан 29 November 2019 в 23:53
поделиться

Мы используем утверждения для посылки .

документа

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

1
ответ дан 29 November 2019 в 23:53
поделиться

Одна причина для вето assert() состоит в том, что возможно написать код, который работает правильно, когда NDEBUG определяется, но перестал работать, когда NDEBUG не определяется. Или наоборот.

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

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

0
ответ дан 29 November 2019 в 23:53
поделиться

На утверждениях можно оставить просто, не определив NDEBUG, таким образом, это не действительно проблема.

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

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

0
ответ дан 29 November 2019 в 23:53
поделиться

Отметьте, выдавание исключения в деструкторе является неопределенным поведением.

0
ответ дан 29 November 2019 в 23:53
поделиться
Другие вопросы по тегам:

Похожие вопросы: