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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In many project I've worked in, assertions were done with a custom macro that had different behaviour in Debug and Release.

In Debug, if the condition is false the debugger is started at that point in the code.

In Release, the error is written to a log file, a warning given to the user, and then the system attempts to save unsaved data. Being in an unknown state, this may fail, but it's worth trying.

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

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

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

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

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

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

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

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

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

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

Потому что они упрощают отладку.

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

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

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

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

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

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

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

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

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

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

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

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

Это похоже на этот код

int i = 1
i = i++ 

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

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

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

Не могу удержаться от цитаты из «Незаменимых Кальвина и Гоббса» с. 180:

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

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

В этом и суть.

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

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

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

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

Я никогда не понимал, что такое утверждения - зачем вам когда-нибудь их использовал?

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

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

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

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

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

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

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

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

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

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

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