C# - где используется класс Debug?
Т.е. Debug не связан с юнит-тестами?
нет
Не заменяет их?
нет
Не используется в них?
нет
Мне казалось, что натолкав в код всяких Debug.Assert и подобных, можно не писать юнит-тесты для этого кода.
Debug.Assert помогает в отладке существующего кода. При этом не просто в отладке, а в в отладке дебаг сборки.
Юнит-тесты работают при каждой сборке, их цель - убедиться, что задуманный функционал не был сломан изменениями.
можно бросить через throw?
-----
Ну попробуй пару сотен тысяч отредактировать поменяв Release/Debug на MyMode со специфическими требованиями...
А из специфических... скажем... все как в релизе, а для 20 классов - дебуг...
Вперед, наш гениальный кодер...
Ну попробуй пару сотен тысяч отредактировать поменяв Release/Debug на MyMode со специфическими требованиями...
А из специфических... скажем... все как в релизе, а для 20 классов - дебуг...
Ну, на всякие извраты - извращённые варианты решений. На то и существуют такие как вы - овнища всякие разгребать. Вам же хорошо платят за это? ))
Код и структура проекта должны быть чистыми, гладкими и шелковистыми ровными и понятными - так гуры всякие учат. А не клубок перепетий, где сам создатель уже через год нихрена не понимает, что происходит... Хотя, как раз на этом и выживают разные сантехники-семизнаки? ))
Я думаю всё же, что нормальные бабки были заработаны не на срочных вызовав "для прочистки труб". За такую работу заказчик не платит сильно много. Может, повыше обычного тарифа кодера на окладе, но всё равно не сильно много. А головняка и срочности у такой работы - хоть отбавляй. Не окупается оно по нервам, по-моему.
я чот тоже не понимаю смысла в этом debug.assertВ режиме debug у меня студия итак реагирует на любое исключение.
да, оно вылезет только при обращёнии к неправильным данным, но даст мне сигнал копать причины.
Ну Debug.Assert'ом можно проверять не только на null. Тут работают любые булевые выражения. Например имеет смысл проверять таким образом длину списка, можно проверять состояние объекта или тип объекта... да много всего. Короче говоря Debug.Assert'ом проверяется ожидаемое состояние. И, кстати, код вполне может так или иначе решать проблему неправильного состояния, но при этом на стадии отладки полезно было бы остановиться в случае ошибки.
Простейший пример:
public bool IsFoo(IEnumarable list)
{
Debug.Assert (list.Length > 0);
int sum = 0;
foreach (int item in list)
{
sum += item;
}
return sum > 0;
}
Покопайся в архиве - у меня как-то инициализированная статическая переменная в процессе работы в нулл падала...
Нее, копаться в архивах я не буду :)
Ошибки в многопоточных приложениях отлавливаются не так легко. С этим никто и не спорит. Ну и статические переменные - зло :)
Ну Debug.Assert'ом можно проверять не только на null. Тут работают любые булевые выражения. Например имеет смысл проверять таким образом длину списка, можно проверять состояние объекта или тип объекта... да много всего. Короче говоря Debug.Assert'ом проверяется ожидаемое состояние. И, кстати, код вполне может так или иначе решать проблему неправильного состояния, но при этом на стадии отладки полезно было бы остановиться в случае ошибки.
Не проще тогда натолкать точек остановка с условиями? Тоже могут проверять сложные условия, тоже работают лишь в дебаге. Зато код захламлять не надо всякими непонятными вызовами классов, странно напоминающими юнит-тесты, но юнит-тестами не являющимися.
Но работают ли точки останова (кто-то так говорит?)
Не совсем понимаю твой вопрос. Ты имеешь в виду, если ты установишь локальные точки останова и запустишь в режиме отладки релизную сборку? Если ты это имеешь в виду, то да, это работает, но с ограничениями. Сейчас с ходу не скажу с какими, помню, что полноценно отлаживать релиз сборку было весьма утомительно.