Non interrompere il debugger a quell’eccezione quando viene lanciato e catturato

In strumenti / eccezioni, ho impostato l’opzione che il debugger si arresta quando viene lanciata un’eccezione. Se è stato catturato o meno.

Come posso escludere un’eccezione da quella regola? Da qualche parte nel mio codice c’è un’eccezione catturata che fa parte della logica del programma. Quindi ovviamente non voglio che questa eccezione fermi il debugger ogni volta che viene colpito.

Esempio: voglio ignorare l’eccezione nullreference (che viene rilevata) nella riga 344. Voglio fermarmi a tutte le altre eccezioni

Se ricordo correttamente, è ansible utilizzare un attributo DebuggerStepThrough sul metodo che contiene il codice che non si desidera che l’eccezione venga triggersta. Suppongo che tu possa isolare il codice che triggers l’eccezione fastidiosa in un metodo e decorarlo con l’attributo.

DebuggerHidden è tuo amico!

Il Common Language Runtime non attribuisce alcuna semantica a questo attributo. È fornito per l’uso da debugger del codice sorgente. Ad esempio, il debugger di Visual Studio 2005 non si arresta in un metodo contrassegnato con questo attributo e non consente di impostare un punto di interruzione nel metodo. Altri attributi del debugger riconosciuti dal debugger di Visual Studio 2005 sono DebuggerNonUserCodeAttribute e DebuggerStepThroughAttribute.

Testato su VS2010 e funziona alla grande.

Anche se DebuggerStepThrough sembra funzionare anche per alcune versioni specifiche del debugger, DebuggerHidden sembra funzionare per una gamma più ampia di situazioni basate sui commenti di entrambe le risposte.

Nota che entrambe le opzioni attualmente non funzionano con i metodi del blocco iteratore o per i metodi asincrono / attendi . Questo potrebbe essere risolto in un successivo aggiornamento di Visual Studio.

DebuggerStepThrough è quello da utilizzare per impedire l’interruzione del debugger in un metodo in cui è presente un try / catch.

Ma funziona solo se non hai deselezionato l’opzione “Abilita solo il mio codice (solo gestito)” nelle impostazioni generali delle opzioni di debug di Visual Studio (menu Strumenti / Opzioni, nodo Debug / Generale) …

Maggiori informazioni su questo attributo su http://abhijitjana.net/2010/09/22/tips-on-debugging-using-debuggerstepthrough-attribute/

DebuggerHidden semplicemente impedirà al Debugger di mostrare il metodo in cui viene lanciata l’eccezione. Invece, mostrerà il primo metodo sullo stack che non è contrassegnato con quell’attributo …

Gli attributi specificati nelle altre risposte (e altri come l’attributo DebuggerNonUserCode ) non funzionano più nello stesso modo per impostazione predefinita in Visual Studio 2015. Il debugger si interromperà sulle eccezioni nei metodi market con tali attributi, diversamente dalle versioni precedenti di VS. Per distriggersre il miglioramento delle prestazioni che ha cambiato il loro comportamento è necessario modificare le impostazioni del registro:

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

Ulteriori informazioni possono essere trovate sul blog di Visual Studio .

(Questo dovrebbe probabilmente essere un commento sulla risposta in alto, ma non ho abbastanza rep)

Non sei in grado di individuare un’eccezione generata in un punto specifico del tuo codice. Tuttavia, è ansible disabilitare le espressioni di un tipo specifico.

Se il proprio codice genera l’eccezione in questione, vorrei renderlo un’eccezione personalizzata, derivata da qualsiasi adattamento, e quindi disabilitare il debugging su questo tipo derivato.

Disabilitare le eccezioni di sistema come NullReferenceException influenzerà l’intero sistema, che ovviamente non è desiderabile durante lo sviluppo.

Si noti che esistono due tipi di comportamenti di interruzione per le eccezioni:

  • Gettato: se selezionato, si interrompe non appena viene lanciata un’eccezione di questo tipo
  • Utente non gestito: se selezionato, interrompe solo se l’eccezione, di questo tipo, non viene gestita da un try / catch.

Puoi rimuovere il check-in “Gettato” per l’eccezione NullReferenceException che ti darà il vantaggio di non infrangere ogni volta che il tuo sistema supera la linea in questione nel tuo codice, ma si rompe ancora se hai qualche exp di NullReference non gestita che si verifica in altre parti del sistema.