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

EP>>>>более того — для формально верифицированного кода они не нужны.
EP>>·>Для формально верифицированного их разве кто-то пишет?
EP>>Я имею в виду то, что после того как есть результат формальной верификации, можно их выключить и это никак не повлияют на корректность.
·>Если код формально верифицируется, то ассерты не нужны. Вообще. Смысл?

Был код с ассертами -> формально верифицировали его -> выключили ассерты. Это иллюстрация на тему:

EP>Отличительная черта assert'ов — в том что они могут быть опционально отключены, более того — для формально верифицированного кода они не нужны.

EP>>Более того, юнит-тест конкретного компонента может успешно пройти при наличии бага, или например двойного бага — то есть false positive. При этом внутренний assert мог поймать эти баги на этом же прогоне. То есть assert'ы это отличное дополнение unit-тестов.
·>А конкретнее? Если ассерт можешь написать, почему это же нельзя выразить тестом?

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

·>>>>>При хорошем покрытии тестами ценность ассертов падает до нуля.
EP>>>>Точно также как и ценность других defensive примочек, а-ля bounds checking
EP>>·>Не точно также же. В проде bounds checking валит исключения
EP>>Да какая разница если у тебя в оттестированном и корректном коде не будет этих исключений?
·>Потенциально будет — если что-то неожиданно поломается, например, кто-то неверно использует компонент или не так "быстренько баг пофиксили".

Так ты определись, либо у тебя "что-то неожиданно поломается", либо "При хорошем покрытии тестами ценность ассертов падает до нуля."

EP>>То есть ты определись — либо у тебя код оттестирован и defensive programming не нужен, либо не оттестирован и ты тестируешь его на своих пользователях
·>Оттестирован на требуемых спекой сценариях.

У тебя в "cпеке" описаны все сценарии, для всех компонент на всех уровнях?

EP>>Conditional
·>А оно правда надо? JIT прекрасно справляется и с тупым finalStaticBool=System.getProperty("DEBUG").....if(finalStaticBool) return.

Я не понимаю что ты хочешь сказать — то что в Java непосредственно этой фичи нет, но не всё так плохо и взамен будет работать какая-то другая техника?
Ну ОК, но как это к обсуждаемой теме относится? То что техника другая, это как-то отменяет факт опциональности ассертов?

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

Без понятия — но проблемы в этом нет. Если нужен over-defenesive, то оставляй assert'ы и в release

EP>>>>В чём ты видишь отличие? Выход за пределы bounds это есть логическая ошибка, которой в корректном коде нет
EP>>·>Эта ошибка явно прописана в спеке языка
EP>>Да какая разница — это и есть логическая ошибка в твоём алгоритме.
·>Так она и сломает мой алгоритм, а не совершенно не относящийся к моему алгоритму код.

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

EP>>>>·>По-моему излишнее усложнение. Собственно на основании чего пользователь будет принимать решение?
EP>>>>1. На основании того какое быстродействие его устраивает
EP>>·>Чем быстрее, тем лучше, очевидно.
EP>>Совсем не очевидно, ибо это не единственный критерий.
·>Т.е. это вообще не критерий, на выбор-то не влияет.

Что? Как раз таки влияет

EP>>>>2. На основании того насколько корректен его код (здесь речь идёт про библиотеку и пользовательский код, ассерты внутри библиотеки могут ловить ошибки в пользовательском коде).
EP>>·>Конечно, корректен, я что ламер некорректный код писать?
EP>>Тогда тебе и не нужен никакой defensive programming
·>Т.е. предлагаешь какие-то субъективные оценки, гадание на кофейной гуще использовать для принятия решения какие ассерты включать, а какие нет?

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

EP>>·>А вообще для этого сценария придумали логи и кастомизируемые (в т.ч. в рантайм) уровни логгирования. Ассерты тут пихать не надо.
EP>>А причём тут логи? Если у тебя условие assert'а сфейлилось — то дальше всё может полететь в тартарары, и лучше всего пристрелить такую программу.
·>Так говорю же, использование ассертов не по назначению. Сфейлилось совсем — брось исключение, оно обработается как надо, а если сфейлилось, но не очень опасно, то пожалуйся в лог и продожи работу. Зачем куда-то лететь-то сразу?

Так assert это и есть жёсткий фейл, семантически не менее (а зачастую более) жёсткий чем обычные исключения.

·>В общем, подытожу. Ассерты нужны если:
·>1. Плохо дело с юнит-тестами. Ассерт куда угодно воткнуть легко и хоть какой-то эффект есть.

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

·>2. Плохо дело с логгированием. Нет нормального способа сообщать о каких-то непредвиденных ситуациях.

Это ты не понимаешь семантику assert'а. Assert это очень жёсткий фейл.

·>3. Плохо дело с обработкой ошибок. Проще грохнуть всё приложение, чем кинуть исключение или нормально обработать ошибочную ситуацию.
·>Т.е. получается что ассерт это такой индикатор code smells.

Нет, и тут не верно. Это уже семантически не assert, так как assert опционален.
А то о чём ты говоришь повсеместно используется в C коде, действительно из-за кривой обработки ошибок, и что характерно не опционально.

Assert это не просто "ошибочная ситуация" а-ля неверный пользовательский ввод и т.п., это БАГ в коде.