ПРОВЕРЯЮТ (…) хорошую практику в кодировании C++?
Кроме того, как это выдерживает сравнение с выдачей исключения, когда что-то идет не так, как надо?
3 ответа
VERIFY () служит той же цели, что и ASSERT () (или стандартная библиотека assert () ) - чтобы вы могли уловить то, чего на самом деле не должно происходить ™ (т.е. настоящая ошибка кода, что-то, что должно быть исправлено перед выпуском). Такие вещи, что, если по какой-то причине выражение ложное, нет смысла продолжать, потому что что-то ужасно, ужасно неправильно.
Это отражено в том факте, что VERIFY () останавливает программу только при ложной оценке при компиляции в режиме отладки - в режиме выпуска это прозрачно. Разница между VERIFY () и ASSERT () заключается в том, что VERIFY () по-прежнему будет оценивать выражение в режиме Release, его просто не заботит результат - тогда как ASSERT () полностью удаляется из программы при компиляции в режиме Release, и поэтому никаких побочных эффектов выражения внутри нее не произойдет.
Исключения более полезны для вещей, которые могут пойти не так, но могут быть восстановлены, поскольку исключения могут обрабатываться другими частями программы.
В Visual C++ есть два макроса для проверки условий: ASSERT и VERIFY.
В режиме отладки они оба ведут себя одинаково: то есть, оба оценивают аргумент и, если результат равен 0, оба завершают программу диалоговым окном assertion failure.
Разница заключается в режиме release. В режиме release ASSERT полностью удаляется из программы: он вообще не оценивает свое выражение. VERIFY, с другой стороны, по-прежнему оценивает выражение, просто игнорирует результат.
Лично я считаю, что если проверка ценна в режиме отладки, то она все еще ценна и в режиме релиза, и вам, вероятно, не следует использовать ни одну из них. Просто выполните проверку и выбросьте исключение (или используйте пользовательский макрос, который расширяется до assert() в режиме отладки и исключения в режиме выпуска).
Вопрос выглядит простым, но за ним скрывается огромная тема: работа с ошибками.
Вкратце, я бы сказал, что assert и verify - это инструменты для использования в процессе разработки , в то время как исключения и проверка ошибок системных вызовов являются нормальными. части производственного кода для работы с ошибками времени выполнения .
Утверждения (применяется к утверждениям и проверкам) - это инструменты, в основном используемые в стиле защитного программирования. Их основная цель - защита от случаев, которые никогда не должны происходить, и программист не знает, что делать, если это произойдет. Обычно его используют для проверки ошибок программирования. Когда во время отладки программы происходит невозможное, вы обычно хотите обнаружить и сообщить об этом как можно быстрее. Это упростит исправление ошибок. Вы можете использовать его с некоторым условием или даже как
assert (false)обычно, чтобы проверить, что ветвь переключателя никогда не перехватывается.Я в основном использую утверждения при работе со сторонним кодом, в поведении которого я не уверен. Для проверки поведения собственного кода, находящегося в процессе разработки, я обычно предпочитаю модульное тестирование.
Теперь, как учил нас Шрёдингер, меры меняют положение вещей. Иногда у вас может быть код, который работает в режиме отладки, когда assert включен, и перестает работать в режиме выпуска. Обычно это симптом скрытой ошибки внутри условия утверждения (побочный эффект, чувствительный ко времени код). Убедитесь, что такой риск сведен к минимуму, но это можно считать плохой практикой, например, подметать пыль за ковер.
Вы также можете использовать verify для быстрого кодирования в качестве основы для мест, где вы еще не настроили реальную обработку ошибок. Я не верю, что вы должны позволять проверять в производственном коде.
Исключения являются нормальной частью потока управления программой. Чаще всего они используются для работы с ошибками, но это не единственное возможное их использование (те, кто использует другие языки, такие как python, знают, о чем я говорю). Их также нельзя рассматривать как единственный инструмент управления ошибками. Если системные вызовы не заключены в библиотеку с поддержкой C ++, они по-прежнему возвращают код ошибки вместо того, чтобы вызывать исключение.
Как правило, исключения должны перехватываться ближайшим объектом, который может разумно их обрабатывать.
Также не все исключения следует рассматривать как фатальные ошибки и останавливать программу. Представьте, что вы имеете дело с сетевой библиотекой потокового видео, которая возвращает сообщения об ошибках через исключения. Если библиотека выдает предупреждение Exception о том, что кадр был пропущен, вы обычно не хотите останавливать программу, а просто подготовьте ее к следующему кадру.
Даже когда лучше всего остановить программу, вы не должны позволять исключению делать это за вас (и у вас еще меньше причин использовать assert для этой цели в производственном коде). Для этой цели всегда должен существовать обработчик исключений верхнего уровня, который выполняет явные вызовы функции exit () или подобного. Если этого не делать, просто показать, что программист не заботился о том, что может случиться, и, вероятно, не думал об этом.