Почему я должен использовать утверждения?

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

Именно в этом суть.

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

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

Утверждения в основном сводятся к следующему: «Зачем отлавливать ошибки, с которыми вы не можете справиться?»

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

У меня никогда не было идеи об утверждениях — зачем вообще их использовать?

Я имею в виду, предположим, что я был водителем формулы, и все требования были связаны с такими вещами, как ремень безопасности, шлем и т. д.

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

А как насчет проверки того, что двигатель установлен? Нужно ли нам проверять это во время гонки?

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

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

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

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

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

Электронная почта от разработчика могла бы достичь этого. Зачем встраивать это в программный код? Это пример проблемы, которая просто не должна возникать. Если это так, мы должны вернуться и исправить программу. Никакая другая форма обработки ошибок невозможна.

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

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

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

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

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

Из Code Complete 2: «Используйте обработку ошибок для ожидаемых условий; используйте утверждения для условий, которые никогда не должны возникать».

Часто цитируемый пример — проверка нуля в знаменателе перед делением.

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

Модульные тесты не являются заменой утверждений.

Потому что они облегчают отладку.

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

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

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

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

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

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

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

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

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

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

Утверждения бесценны при рефакторинге, я думаю. Если вы хотите заменить alogrihm1() алгоритмом2(), вы можете использовать их оба и утверждать, что результаты равны. Затем вы можете постепенно отказаться от алгоритма1()

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

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

В Code Complete есть раздел, который говорит что-то вроде. Каждый раз, когда вы пишете if без каких-либо других параметров, вы, возможно, что-то упускаете.

Это как этот код

int i = 1
i = i++ 

Обычный программист никогда не будет думать о том, что произойдет, если i будет отрицательным в более позднем коде. Существует небольшая вероятность того, что ваш код вызовет переполнение, а такие языки, как java, перейдут от max int к min int, и вы получите очень большое отрицательное число. Это все случаи, о которых вы обычно говорите. Это никогда не случится. Но что делает ваша программа, если это произойдет? Итак, если вы знаете, что есть что-то, что, по вашему мнению, никогда не произойдет, проверьте это или нет и поместите утверждение false в предложение else, которое никогда не произойдет, вместо того, чтобы программировать оператор else. Таким образом, ваша программа должна полностью рухнуть в тот момент, когда вы перестанете быть уверены в том, что она делает. В производственном коде должно быть что-то отличное от сбоя, например, информирование пользователя, сопровождающего и последующий выход.

Еще одно использование утверждений — проектирование, основанное на контракте. Вы указываете контракт с вашим интерфейсом, и в зависимости от вашего места в программе вы утверждаете свой ввод, но гораздо более важно, что вы утверждаете свой вывод два.

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

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

В Debug, если условие ложно, отладчик запускается в этой точке кода.

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

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

Вот действительно простой пример того, как утверждение можно использовать в разработке.

A(char* p)
{
    if(p == NULL)
        throw exception;

    B(p);
    C(p);

}

B(char* p)
{
    assert(p != NULL);
    D(p);
    do stuff;
}

C(char* p)
{
    assert(p != NULL);
    D(p);
    do stuff;
}

D(char* p)
{
    assert(p != NULL);
    do stuff;
}

Вместо вызова «if(p == NULL) throw exception;» 5 раз, вы просто вызываете его один раз, чтобы вы уже знали, что это не NULL при вводе B(), C() и D(). В противном случае утверждение завершится на этапе разработки, потому что вы «изменили код!» не из-за «ввода пользователя».

Это может заставить код работать намного быстрее в релизной версии, потому что все, что вам нужно сделать, это вызвать gcc с «-DNDEBUG», поэтому все утверждения не будут скомпилированы, а все «ненужные проверки» будут удалены в исполняемом файле.

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

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

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

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

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

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

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

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

Не могу не процитировать "Непременных Кальвина и Гоббса" с. 180:

Прежде чем спускаться с такого крутого холма, нужно всегда проверять безопасность своих саней.
Верно.
Ремни безопасности? Нет.
Сигналы ? Нет.
Тормоза? Нет.
Рулевое управление ? Нет.
ХУЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕ

Утверждение следует использовать, когда вы делаете что-то подобное

a = set()
a.add('hello')
assert 'hello' in a

or

a = 1;
assert a == 1; // if ram corruption happened and flipped the bit, this is the time to assert

Что касается исключений, это то, с чем вы имеете дело программно:

while True:
  try:
    data = open('sample.file').read()
    break // successfully read
  except IOError:
    // disk read fail from time to time.. so retry
    pass

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

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

Для всего остального сгенерируйте исключение.

Для других ответов на этот вопрос

Макрос assert() используется для проверки условий или допущений, которые не должны встречаться в программе. Например, индекс массива всегда должен быть > 0. Другое предположение может быть 2+2 == 3+1.

Таким образом, используя assert(), мы можем проверить такие предположения, и пока они оцениваются как истинные, наша программа работает нормально. Когда они ложны, программа завершается.

подробнее здесь https://www.softwaretestinghelp.com/assert-in-cpp/

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

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

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

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

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

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

В большей части производственного кода, который я видел, я заметил в основном два способа справиться с этим: намазать утверждения по всему коду, а затем оставить хороший набор в производстве. У этого есть приводящая в бешенство тенденция просто закрывать приложение для пользователя, я еще не видел, чтобы Assert изящно подвел систему .... он просто подвел ее ... бум ... ушел ... конечный пользователь просто сказал: «WTF ошибка утверждения по адресу 0x330291ff!!!"

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

НИ ОДИН СПОСОБ не поможет получить хорошую стабильную систему. Конечно, вы можете использовать утверждения в своем бета-коде и удалить их все в своем производственном коде... но какого черта вам удалять свои сети безопасности, потому что это производство. Я был бы очень удивлен, если бы все эти проверки нанесли вред производительности вашей системы.

Создайте себе хорошую схему обработки исключений и... ей-богу... ОСТАВЬТЕ ЭТО ЗДЕСЬ, вы получите гораздо более значимую информацию о вашей системе, и если все сделано правильно, всегда в контексте, чем наличие какой-то глубокой библиотеки, выбрасывающей утверждения, потому что чего-то не хватает.

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

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

И да... обычно код, который дает сбой в продакшене, редко имеет мое имя сверху.