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

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

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

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

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

EP>>>Там некоторые из них опциональные, и не попадают в Release.
EP>·>Ух ты. Это как устроено? Что-то не могу разобраться...
EP>Conditional
EP>

EP>Conditional methods allow developers to create methods whose calls can be placed in the code and then either included or omitted during compilation based on a preprocessing symbol.

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

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

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

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

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

EP>·>А ты как корректность своего кода оцениваешь?
EP>Зависит от конкретного случая — различные комбинации unit/integration тестов, разбиение на классы эквивалентности, поиск изоморфизмов, assert'ы на пред/пост-условия и ванрианты/инварианты, доказательства. Вот до чего пока не доходил, так это до выражения доказательств на формальных языках и их дальнейшей автоматизированной проверки.

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

В общем, подытожу. Ассерты нужны если:
1. Плохо дело с юнит-тестами. Ассерт куда угодно воткнуть легко и хоть какой-то эффект есть.
2. Плохо дело с логгированием. Нет нормального способа сообщать о каких-то непредвиденных ситуациях.
3. Плохо дело с обработкой ошибок. Проще грохнуть всё приложение, чем кинуть исключение или нормально обработать ошибочную ситуацию.

Т.е. получается что ассерт это такой индикатор code smells.