Здравствуйте, ·, Вы писали:

EP>>·>Если код формально верифицируется, то ассерты не нужны. Вообще. Смысл?
EP>>Был код с ассертами -> формально верифицировали его -> выключили ассерты. Это иллюстрация на тему:
·>Если код формально верифицирован — ассерты можно тупо удалить. Формальная верификация — сильная, но дорогая техника доказательства корректности кода, которая полностью заменяет ЮТ и ассерты.

Да, после верификации ассерты можно хоть удалить. Я этот пример привёл именно в качестве иллюстрации на тему опциональности assert'ов

EP>>При этом assert может элементарно проверять состояние между ошибками. А вот соответствующий юнит-тест мог бы быть на порядки менее очевидным, если вообще возможным.
·>Если ты вдруг полагаешь, что где-то может быть ошибочное состояние (т.е. хочешь написать там ассерт), то
·>либо воспроизведи это состояние тестом, т.е. ассерт не нужен;

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

·>либо почеши голову и убедись, что это состояние невозможно, т.е. ассерт не нужен.

assert помимо всего прочего может ловить нарушения preconditions, а конкретнее выстреливать во время интеграции компонентов. Ты не можешь "почесать голову" и убедится в том, что все компоненты (которых ты ещё даже не видел) обязательно будут удовлетворят предусловиям.
Более того, если например ты используешь чужой алгоритм с ассертами на предусловия — то ты фактически получаешь эти все проверки бесплатно.

EP>>>>То есть ты определись — либо у тебя код оттестирован и defensive programming не нужен, либо не оттестирован и ты тестируешь его на своих пользователях
EP>>·>Оттестирован на требуемых спекой сценариях.
EP>>У тебя в "cпеке" описаны все сценарии, для всех компонент на всех уровнях?
·>Зачем на всех уровнях? Ошибка на уровне юнитов будет падать сразу с каким-нибудь bounds checking и видна немедленно и везде.

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

EP>>>>·>При релизном использовании отключены.
EP>>>>Совсем необязательно — я их видел в коммерческом продукте имеющем сотни миллионов установок
EP>>·>Гы-гы. Ведь явно не от хорошей жизни, им тупо пришлось использовать ассерты не по назначению.
EP>>Без понятия — но проблемы в этом нет. Если нужен over-defenesive, то оставляй assert'ы и в release
·>Это не имеет смысла, используют инструмент не по назначению. Это уже тогда не ассерты, а обычные проверки.

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

·>Т.е. придумали себе сложность и героически её решаем.

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

·>"Опциональный жесткий фейл". Это не звучит для тебя как оксюморон?

Нет. Нарушение условия ассерта это жёсткий фейл, баг в программе. Точно также как и нарушение любого пред/пост-условия вокруг каждого выражения (а-ля Hoare Triple).
При этом несмотря на то что это жёсткие фейлы, в релизной версии нет даже и малой части всех этих проверок, а некоторые и вовсе неразрешимы. Вот у тебя есть проверки пред/пост-условия вокруг каждого выражения?

EP>>Ассерты полезны и когда плохо и когда хорошо с юнит-тестами. Работают и при юнит и при интеграционных тестах. Позволяют легко выявлять двойные ошибки и подобное. "Втыкаются" элементарно, и сразу по месту. Плюс служат дополнительной документацией (фактически проверяемой)
·>Вот и воткни ЮТ. Почему обязательно ассерт?

Перечитай ещё раз то, на что ответил — например про то что ассерты работают и при интеграционных тестах.