Какова стратегия, если утверждение терпит неудачу

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

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

Если вы находитесь в лагере, который говорит: «А что, если утверждения не работают? Мне нужно их поймать!» тогда вы упускаете суть. В таком случае спросите себя: почему вы просто не генерируете исключение (или не обрабатываете ошибку другим способом)?

Вообще говоря, assert - это не просто сокращение для «если условие не выполнено, генерировать исключение» (ну, иногда это операционная семантика, но не денотационная семантика). Скорее, ошибка утверждения означает, что приложение находится в состоянии, которое разработчик даже не считает возможным. Вы действительно хотите, чтобы код продолжал выполняться в таком случае? Ясно (я бы сказал) Нет.

Защитное программирование всегда лучше. Вы всегда должны предполагать, что, несмотря на все ваши тесты, ваше приложение будет поставляться с ошибками. Таким образом, в ваших интересах добавлять проверки NULL в ситуациях, когда вы можете избежать использования указателя NULL и просто двигаться дальше.

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

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

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

Строго говоря, второй код имеет избыточность.

void f(int *p)
{
  assert(p);
  if (p)    // Beats the purpose of assertion
  {
    p->do();
  }
}

Утверждение означает, что произошла ошибка. Что-то неожиданное / необработанное. В приведенном выше коде либо

1) Вы правильно обрабатываете случай, когда p равно нулю. (не вызывая p-> do ()) - что якобы является правильным / ожидаемым действием. Однако тогда это утверждение является ложной тревогой.

2) С другой стороны, если без вызова p-> do () что-то пойдет не так (может быть, дальше в коде или на выходе), тогда утверждение верно, но в любом случае нет смысла продолжать.

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

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

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

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

Как вы упомянули, утверждения полезны для отладки. Они никогда не должны попадать в производственный код (в скомпилированном виде, конечно, можно обернуть их в #ifdefs)

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

void f(int *p)
{

  if (!p)
  {
    do_error("FATAL, P is null.");
  }

  p->do();
}

Где do_error - это функция, которая регистрирует ошибку и полностью завершает работу.

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

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

Поскольку многие люди комментируют перевод утверждений в режим выпуска:

В том, над чем я работаю, очень важна эффективность (иногда выполнение больших наборов данных занимает от десятков часов до нескольких дней). Следовательно, у нас есть специальные макросы, которые утверждаются только в отладочном коде (выполняются во время QA и т. Д.). Например, утверждение внутри цикла for определенно является накладным расходом, и вы, возможно, захотите избежать его в коде выпуска. В конце концов, если все в порядке, утверждения не должны терпеть неудачу.

Один из примеров, когда утверждения кода выпуска хороши, - это когда логика вообще не должна воздействовать на конкретную ветвь кода. В этом случае assert (0) подойдет [таким образом, любой вид assert (0) всегда можно оставить в коде выпуска].