Не останавливайте отладчик в ЭТОЙ исключительной ситуации, когда он брошен и пойман

Question

В инструментах / исключениях я установил параметр, при котором отладчик останавливается при возникновении исключения. Будь это пойман или нет.

Как исключить исключение из этого правила? Где-то в моем коде есть пойманное исключение, которое является частью логики программы. Поэтому я, очевидно, не хочу, чтобы это исключение останавливало отладчик при каждом его нажатии.

Пример: я хочу игнорировать исключение nullreference (которое перехватывается) в строке 344. Я хочу остановиться на всех других исключениях

Answer 1

DebuggerHidden ваш друг!

Общеязыковая среда выполнения не придает семантики этому атрибуту. Он предоставляется для использования отладчиками исходного кода. Например, отладчик Visual Studio 2005 не останавливается в методе, помеченном этим атрибутом, и не позволяет устанавливать точку останова в методе. Другими атрибутами отладчика, распознаваемыми отладчиком Visual Studio 2005, являются DebuggerNonUserCodeAttribute и DebuggerStepThroughAttribute.

Протестировано на VS2010 и прекрасно работает.

Хотя DebuggerStepThrough, кажется, также работает для некоторых конкретных версий отладчика, DebuggerHidden, кажется, работает для более широкого диапазона ситуаций, основанных на комментариях к обоим ответам.

Обратите внимание, что в настоящее время обе опции не работают с методами блока итераторов или асинхронными / ожидающими методами . Это может быть исправлено в более позднем обновлении Visual Studio.

Answer 2

Если я правильно помню, вы можете использовать атрибут DebuggerStepThrough в методе, который содержит код, который вы не хотите запускать исключение. Я полагаю, вы можете изолировать код, который вызывает раздражающее исключение в методе, и украсить его атрибутом.

Answer 3

DebuggerStepThrough - это тот, который используется для предотвращения сбоя отладчика в методе, в котором есть try / catch.

Но это работает только в том случае, если вы не сняли флажок «Включить только мой код (только управляемый)» в общих настройках параметров отладки Visual Studio (меню «Инструменты / Параметры», «Отладка узла / Общие») ...

Больше информации об этом атрибуте на http://abhijitjana.net/2010/09/22/tips-on-debugging-using-debuggerstepthrough-attribute/

DebuggerHidden просто не позволит отладчику отображать метод, в котором выдается исключение. Вместо этого он покажет первый метод в стеке, который не помечен этим атрибутом ...

Answer 4

Атрибуты, указанные в других ответах (и другие, такие как атрибут DebuggerNonUserCode), по умолчанию больше не работают по умолчанию в Visual Studio 2015. Отладчик будет работать с исключениями на рынке методов с этими атрибутами, в отличие от старые версии VS. Чтобы отключить повышение производительности, которое изменило их поведение, необходимо изменить параметр реестра:

reg add HKCU\Software\Microsoft\VisualStudio\14.0_Config\Debugger\Engine /v AlwaysEnableExceptionCallbacksOutsideMyCode /t REG_DWORD /d 1

Дополнительную информацию можно найти в блоге visual studio .

(Вероятно, это должен быть комментарий к верхнему ответу, но мне не хватает представителя)

Answer 5

Вы не можете выделить исключение, выброшенное в определенном месте в вашем коде. Однако вы можете отключить исключения определенного типа.

Если ваш собственный код выдает исключение, о котором идет речь, я бы сделал его настраиваемым исключением, полученным из любого соответствия, а затем отключил бы отладку в этом производном типе.

Отключение системных исключений, так как NullReferenceException повлияет на всю систему, что, конечно, нежелательно при разработке.

Обратите внимание, что для исключений существует два вида прерываний:

• Брошенный: если выбрано, прерывается, как только выбрасывается исключение этого типа
• User-unhandled: если выбрано, прерывается, только если исключение этого типа не обрабатывается try / catch.

Вы можете снять флажок «Брошено» для исключения NullReferenceException, которое даст вам преимущество не прерывать каждый раз, когда ваша система пропускает соответствующую строку в вашем коде, но все же прерывать, если у вас есть какое-то необработанное исключение NullReference, возникающее в части системы.