ну и наверное стабильность проги тоже идет в жертву, она же ляжет.

когда как там могла бы вернуться пустая строка из имени узла и т.п.

Если код сделает что-то не то есть два варианта: он упадёт (разницы с вариантом с ассертом нет) либо он не упадёт, а просто будет в невалидном состоянии. Невалидное состояние можно отловить без ошибок.

null это ок проверять на выходе из чужого кода

Небольшие расходы

Но вообще падение на нулл благо если стек трейс в корке сохраняется

не очень понятно, ты за чьи ассерты переживаешь? чужой либы или свои поверх этой либы?

Мой опыт и я сомневаемся в успехе концепции, когда если из кода убрать защиты и подстраховки, то работать оно будет по-прежнему и на нештатные ситуации приложение будет реагировать предсказуемо как и в режимах отладки, поэтому я боюсь за всё). Строгой классификации ситуаций с проверками нет, что, когда и для чего предназначено, по законам Мерфи вместо assert будет enforce, вместо enforce assert, вместо enforce\эксепшена контракт и т.п. комбинаторика. Мне кажется, что менее рисково не морочиться и включить вообще всё, вернее не выключать через release. Для какого-нибудь хайлоада\эмбеддеда это уже другой вопрос. И мне кажется название этого флага может ввести в заблуждение, я бы предпочел там видеть часть слова unsafe или что-то такое. Обычно релиз наоборот, предполагает повышение стабильности и безопасности, а не наоборот, имхо. Надеюсь, он там что-то в консоль пишет, а то кто-нибудь соберет себе релиз с выключенными проверками.

Так ассерты это когда код падает без возможности восстановиться. Такой код априори нестабильный.

опять ничего не понял

эта стабильность\нестабильность, восстановимость\невосстановимость, обязательность проверок\необязательность понятия очень относительные. Для cli-приложения критическая ошибка прервет поток управления, для гуевого это уже вопрос, через гуи изменять состояние программы намного проще, а если что-то не работает, то гуи могут представлять инфу об ошибке, что предполагает частичное сохранение работы. Гуи в конце концов могут использоваться как глобальный хандлер всех ошибок, для такого кейса критическая ошибка уже не для всей программы, а для какого-то отдельного модуля, а хандлер должен работать всегда.. ну или же передать ошибку кому-нибудь другому, если в нем самом будет ошибка.

С таким же успехом ты можешь перехватывать null pointer без всяких ассертов

Критические ошибки в сердце программы — это не совсем то что хочется в релизе

А если программа не может работать в сложившихся условиях — она и так упадёт

Собственно в чём разница?

Только что в release она попытается не упасть

я б не сказал, что мне нужны эти попытки не проверять то, что раньше проверялось. Пока буду рассматривать release mode как некий уровень дополнительных оптимизаций, которые можно включить по необходимости, как последний шанс повысить производительность и то после исчерпывания всех остальных вариантов. Да и тут тоже вопрос, если начинается игра в байты и микросекунды, то тот ли стек выбран или все же нет, кгм....

а контракты хороши, хороши...

Ну это конкретно тебе не надо, ты всё ещё можешь врубить в release нужные проверки

По умолчанию отрубать ассерты и контракты — более чем здраво