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

S>·>Да нет жеж. Пиши, проверяй, ломай, но без ассертов. Заменяй ассерты чем-то другим. Почему ты считаешь их незаменимыми? Используй другие инструменты.
S>Дык какие же? Помимо юнит-тестов в смысле.
Почему "помимо"?

S> Логгер — не вариант, очевидно. Кто за его выхлопом следить-то будет?
Кого настроишь — тот и будет следить. Лог-аппендеры при желании могут даже окошко могут нарисовать.

S>>>Комбинацией из ассертов + интеграционными тестами такие вещи ловятся на раз-два. Кто ленится — получает вот

Автор: DreamMaker
Дата: 28.08.16

это

Автор: Pavel_Agurov
Дата: 12.01.15

в подарок.
S>·>В проде он ничего не получит, получит unspecified behaviour, т.к. по определению в проде ассерты отключаются.
S>Ну, это догматизм ненужный. Если разработчик решает отключить ассерты в продакшне (не выборочно, только тяжёлые, а вообще все) — то обвинять надо точно не ассерты.
Мда, похоже, тут спор частично терминологический. Под ассертами понимаются обычно такие проверки, которые отрубаются в проде. А если это такие проверки, которые работают всегда и везде, кидая исключение, то они ничем неотличимы от обычных проверок типа if(x) throw Exception, кроме, может быть, синтаксиса.

S>·>А в дебаге он получит что-то лишь в том случае, если _догадается_ написать ассерт. А раз догадался написать ассерт — почему не написал тест?
S>Потому что далеко не всегда получается придумать способ нарушить ассерт на текущем коде, иногда это в принципе невозможно.
Если это и вправду "в принципе невозможно" — то накой тогда ассерт?

S>"Что-то может пойти не так" постфактум. Я давал уже кучу примеров — и с локалью, которая появилась после написания кода, и с багом с "потерянным" часом в новом году, и с "неожиданной" обработкой путей с точкой в конце.
S>Как-ещё по вашему можно защищаться от подобных ошибок?
Чем не устраивает то что я перечислял уже — тестами, логгированием, корректной обработкой таких ошибок, етс?