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

·>И чем это лучше чем банальный:
Как минимум тем, что отлавливает ещё и ActiveEditor == null.

Если серьёзно, то конкретно в этом примере смысла расставлять ассерты нет, проще код поправить. А вот подстелить соломку в местах, где закладываешься на текушее поведение, аля

        protected override void RunCore(... List<Measurement> resultMeasurements)
        {
            DebugCode.BugIf(resultMeasurements.Count>0, "resultMeasurements not empty.");
            DebugCode.BugIf(resultMeasurements.Capacity < iterationCount, "resultMeasurements capacity not set.");

иногда спасает. Буквально вчера этот ассерт словил баг с передачей не того списка в метод.

S>>Т.е. для отладочного кода — падаем с понятным сообщением, для релиза — никаких проверок и (скорее всего) падаем с NRE.
·>Фи. Или падаем, но не сразу — если combo используется где-то в другом участе кода чуть позже — счастливой отладки.
Ну а что мешает оставить ассерт и для релизных сборок? Я ж не зря написал условие, когда достаточно только отладочного ассерта:

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

·>ассерты фтопку.
А аргументы какие-нить будут, кроме как "мне не нравится"? А то типовая ситуация с проектами "ассерты не нужны" выглядит вот так: тесты зелёные, CI настроен, покрытие норм, форкаем, ставим ассерты — и оппа баг раз, оппа баг два, упс — недоработка три и тыды и тыпы.

Причём сам код — отличный и с сценариями авторов проблем нет вообще. Проблема с непредусмотренными сценариями. Для них тестов нет, проверок нет и распутывание ошибок превращается в натуральный квест типа такого.

Ассерты подобные косяки ловят на раз-два, т.к. они работают всегда, а не проверяются только в одном тесте из нескольких тысяч.