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

1. Таки спасибо, интересный спор получился У меня появляется настойчивое подозрение: главная причина спора в том, что ты понимаешь под ассертами что-то большее, чем просто "проверка в коде". Т.е. спор в итоге чисто про терминологию.

2. По пунктам.

·>Так ассерт не может в принципе "гарантировать, что ни одно из них не передаёт, скажем, 42". Он будет лишь что-то (не)делать, если 42 таки передалось.
Может-может. Достаточно покрыть тестами основные сценарии использования и можно с относительной уверенностью говорить, что критичной для нашего кода ошибки нет. Даже если ошибка и вылезет, скажем, у одного из клиентов, то оставленный в коде ассерт сразу её отловит и сообщит куданадо (с помошью клиента или автоматом — это уже детали реализации). В ближайшем патче ошибку исправят.

Сам понимаешь, при таком раскладе шанс поймать ошибку на порядки (серьёзно на порядки) выше, чем когда возможность ошибки проверяется в одном тесте из тысячи.
Как дополнительный бонус — у нас значительно вырастает полезность тестов, особенно интеграционных. Они проверяют не только входы-выходы, но и корректность кода в целом.


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

·>Ну обычно ERROR уровень таки не оставляют незамеченным.
Юнит-тестами? Да легко. Кто в них лог проверяет?


S>>·>Мда, похоже, тут спор частично терминологический. Под ассертами понимаются обычно такие проверки, которые отрубаются в проде. А если это такие проверки, которые работают всегда и везде, кидая исключение, то они ничем неотличимы от обычных проверок типа if(x) throw Exception, кроме, может быть, синтаксиса.
S>>А, это из плюсов, наверно, в наследство досталось. Глянь тут
·>Так там я это и прочёл:
А вот не надо выборочно цитировать Выделил:

When a program is deployed to production, assertions are typically turned off to avoid any overhead or side effects they may have…

Если выделенное не является проблемой для софта — смысл отключать ассерты?

S>>или тут. Везде основное свойство ассертов — "проверяет ожидания программиста", а не "не работает в релизе".
·>А ты сам-то читал?

О, снова неполная цитата. Там же дальше написано:

Normally, you don't want users to see assertion messages
...
For highly robust code, assert and then handle the error anyway.

Что считать robust code — это уже вопрос предпочтений, про сообщать пользователю — это чисто вопрос реализации, насильно спамить никто не заставляет.
Мы предпочитаем отслеживать ошибки даже в продакшне, а не пропускать их молча, но это от реальных требований зависит.


S>>Не дешевле было просто ассерт поставить?
·>Лучше в DoWork вставить if(!inited) throw Exception.
Блин, мы по кругу ходим. Я ж уже спрашивал: чем ассерты от исключений отличаются? Кроме того, что их можно переиспользовать без копипасты и выборочно исключать в критичных для производительности местах?

·>У тебя публичный контракт с тремя методами Init/DoWork/Clear — а соответственно любой пользователь класса может не следовать этому контракту, значит его надо явно проверять. То что у тебя на данный момент в коде нет таких пользователей это тебе не даёт право надеяться на авось — такой плохой пользователь может получиться позже — из-за неудачного рефакторинга или добавления новой функиональности, а в твоём случае такой пользователь был, но был неявный, из-за рефлексии в этом сериализаторе, видимо.

Ну да, о чём и речь. Тут никак без ассерта/проверки не обойтись, одни тесты никак не помогут.