Comments 10
На самом деле и правильно, что не стоит ловить переполнение стека, но вот когда я учил .Net и при запуске юнит-тестов всплыла неявная рекурсия и весь тестовый движок полетел в "Windows ищет способ исправления проблемы" без рапорта, что и где, было обидно. В противовес JVM, где исключение хоть так же нет причин ловить, тестовые фреймворки не ложатся под его весом, а честно сообщают об упавшем тесте и идут дальше работать.
Прошу прощения, я вас не понял — Решарпер смог дальше тесты запускать или как? Из ваших слов вижак успешно упал, что для меня не очень ожидаемое поведение.
Все-таки он не «успешно упал», а «успешно поймал» (catch) =)
А, уже лучше, чем было у меня, но всё равное такое ИМХО. Stacktrace был?
Тем не менее, в сессии видно, какой именно из тестов упал, в сообщении явно указано про Stack overflow exception — что скорее всего подразумевает рекурсию. В большинстве случаев, на мой взгляд, этого вполне достаточно, чтобы локализовать проблему. Если нет — то видимо, есть проблемы с архитектурой в целом, ИМХО.
С одной стороны да, а с другой показать дно стека было бы удобно. Это не вопрос архитектуры, скорее насколько платформа помогает искать лажу.
Кроме того, при запуске теста в том же Решарпере в режиме дебага он приостанавливает исполнение, как на обычном эксепшне:
Да и студия при запуске тестов сама предлагает подебажить:
[DotNetBook] Время занимательных историй: исключительно исключительные ситуации