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

EP>·>Если код формально верифицирован — ассерты можно тупо удалить. Формальная верификация — сильная, но дорогая техника доказательства корректности кода, которая полностью заменяет ЮТ и ассерты.
EP>Да, после верификации ассерты можно хоть удалить. Я этот пример привёл именно в качестве иллюстрации на тему опциональности assert'ов
А так же на тему ненужности assert'ов

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

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

EP>>>·>Оттестирован на требуемых спекой сценариях.
EP>>>У тебя в "cпеке" описаны все сценарии, для всех компонент на всех уровнях?
EP>·>Зачем на всех уровнях? Ошибка на уровне юнитов будет падать сразу с каким-нибудь bounds checking и видна немедленно и везде.
EP> bounds checking это лишь мизерная часть проверки ошибочных состояний, ассерты используются далеко не только для bounds checking.
Для чего ещё? Ну там null-checks, валидность параметров и т.п. Может какая-то доля процента и будет чем-то интересным, но её лучше тогда явно протестировать.

EP>>>·>Гы-гы. Ведь явно не от хорошей жизни, им тупо пришлось использовать ассерты не по назначению.
EP>>>Без понятия — но проблемы в этом нет. Если нужен over-defenesive, то оставляй assert'ы и в release
EP>·>Это не имеет смысла, используют инструмент не по назначению. Это уже тогда не ассерты, а обычные проверки.
EP>Ассерты в первую очередь нацелены на поимку багов — нарушение инвариантов, вариантов, пред/пост-условий.
EP>У них семантика другая нежели чем у обычных проверок. Обычные проверки нельзя выкинуть даже из формально верифицированного кода.
Неотключённые ассерты в релизе по сути и есть эти сами обычные проверки. Т.е. были ассерты, а семантику поменяли.

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

EP>Вот у тебя есть проверки пред/пост-условия вокруг каждого выражения?
Нет. А у тебя ассерты есть вокруг каждого выражения?

EP>Перечитай ещё раз то, на что ответил — например про то что ассерты работают и при интеграционных тестах.
И что? Интеграционные тесты как правило тестируют сильно меньше, чем юнит. И ещё меньше, чем возможно в релизе. Почему вдруг интеграционные тесты стали важнее релиза?