Non interrompere il debugger su QUELLA eccezione quando viene lanciata e catturata

91

In strumenti / eccezioni, ho impostato l'opzione che il debugger si arresti quando viene generata un'eccezione. Che sia catturato o meno.

Come escludo un'eccezione a quella regola? Da qualche parte nel mio codice c'è un'eccezione rilevata che fa parte della logica del programma. Quindi ovviamente non voglio che l'eccezione fermi il debugger ogni volta che viene colpito.

Esempio: desidero ignorare l'eccezione nullreference (che viene rilevata) sulla riga 344. Voglio fermarmi a tutte le altre eccezioni

— MichaelD
fonte

6

Quando questa eccezione fa parte della logica di programmazione (pensa, se devi davvero implementarla in questo modo), allora dovrebbe essere almeno un'eccezione derivata creata da te. In questo modo puoi applicare la soluzione di Brian.

— tanascius

Ecco il problema: stackoverflow.com/questions/1957907/…

— MichaelD

2

@tanascius - +1 Sono d'accordo nella maggior parte dei casi Le eccezioni non sono il modo migliore per prendere una decisione logica; tuttavia in alcuni casi come quando la deserializzazione della gestione delle eccezioni è talvolta inevitabile, quindi throw> catch> handle è l'unica opzione ragionevole.

— jpierson

2

@Ando scusa il mio male. La moderazione di più schede contemporaneamente è efficiente, ma non sempre accurata.

2

@tanascius: potresti ancora dover rilevare un'eccezione del framework nota prima di poter lanciare la tua in risposta. Il tuo suggerimento non è sempre possibile.

— Dan Puzey

40

Se ricordo bene, puoi usare un DebuggerStepThroughattributo sul metodo che contiene il codice che non vuoi che l'eccezione faccia fuoco. Suppongo che tu possa isolare il codice che genera la fastidiosa eccezione in un metodo e decorarlo con l'attributo.

— Chris Chou
fonte

31

Dalla risposta di Malinger e dalla mia esperienza, questa risposta sembra essere errata. L' DebuggerStepThroughattributo non influisce sul comportamento del debugger con eccezioni di prima possibilità.

— Michael Petrotta

5

@ Tim, ho provato e NON si ferma. cassa my risposta: stackoverflow.com/questions/1420390/3455100#3455100

— Shimmy Weitzhandler

1

+1 funziona in VS2010 per .NET 4.0 puro e codice Silverlight 4 per eccezioni non gestite.

— Mike Post

6

Nota importante: questo non funziona per i metodi di tipo async-await. Maggiori informazioni qui

— i3arnon

8

Per MSDN, l' DebuggerStepThroughattributo non ha alcun significato per CLR. Viene interpretato dai debugger. Sembra che non funzioni in modo affidabile in una serie di circostanze e DebuggerHiddenfunzionerà in modo affidabile stackoverflow.com/a/3455100/141172

— Eric J.

64

DebuggerHidden È tuo amico!

Common Language Runtime non associa semantica a questo attributo. Viene fornito per essere utilizzato dai debugger del codice sorgente. Ad esempio, il debugger di Visual Studio 2005 non si ferma in un metodo contrassegnato con questo attributo e non consente l'impostazione di 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 DebuggerStepThroughsembra funzionare anche per alcune versioni specifiche del debugger, DebuggerHiddensembra funzionare per una gamma più ampia di situazioni in base ai commenti a entrambe le risposte.

Notare che entrambe le opzioni attualmente non funzionano con i metodi di blocco dell'iteratore o per i metodi asincroni / attesi . Questo potrebbe essere risolto in un successivo aggiornamento di Visual Studio.

— Shimmy Weitzhandler
fonte

lavorando su VS2008. Devi applicarlo all'intero metodo, incluso il blocco di cattura, o ti fermerai da qualche altra parte

— Mark Heath

1

Ho aggiunto quell'attributo a un metodo e il debugger si è semplicemente fermato sul methond chiamante di esso. Mi sto perdendo qualcosa?

— Doogal

1

È così che dovrebbe essere. per evitare ciò, dovrai gestire l'eccezione ... O in alternativa contrassegnare anche il metodo del chiamante DebuggerHidden...

— Shimmy Weitzhandler

1

Si noti che l'attributo DebuggerStepThrough dovrebbe essere sufficiente per evitare l'interruzione delle eccezioni. DebuggerHidden agisce come una combinazione di DebuggerNonUserCode e dell'attributo DebuggerStepThrough.

— jpierson

1

Purtroppo, questo non funziona se il metodo in questione è un metodo iteratore : /

— Roman Starkov

14

DebuggerStepThrough è quello da utilizzare per impedire al debugger di interrompere 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 impedirà semplicemente al debugger di visualizzare il metodo in cui viene generata l'eccezione. Invece, mostrerà il primo metodo sullo stack che non è contrassegnato con quell'attributo ...

— Valery Letroye
fonte

1

Si noti che questo non funziona più per impostazione predefinita in VS 2015, vedere il blog VS per come abilitarlo

— bhh

Purtroppo il work-around VS 2015 non funziona per VS 2019.

— Jonathan Allen

13

Gli attributi specificati nelle altre risposte (e altri come DebuggerNonUserCodeattributo) non funzionano più allo stesso modo per impostazione predefinita in Visual Studio 2015. Il debugger interromperà le eccezioni nel mercato dei metodi con quegli attributi, a differenza delle versioni precedenti di VS. Per disattivare il miglioramento delle prestazioni che ha modificato il loro comportamento, è necessario modificare un'impostazione del registro:

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

Maggiori informazioni sono disponibili sul blog di Visual Studio .

(Questo dovrebbe probabilmente essere un commento sulla risposta migliore ma non ho abbastanza rep)

— bhh
fonte

3

Non sei in grado di individuare un'eccezione generata in una posizione specifica nel codice. Puoi comunque disabilitare le eccezioni di un tipo specifico.

Se il tuo codice genera l'eccezione in questione, la renderei un'eccezione personalizzata, derivata da qualsiasi cosa si adatti, e quindi disabiliterei l'interruzione del debug su questo tipo derivato.

La disabilitazione delle eccezioni di sistema come NullReferenceException interesserà l'intero sistema, il che ovviamente non è desiderabile durante lo sviluppo.

Nota che ci sono due tipi di comportamenti di interruzione per le eccezioni:

Lanciato: se selezionato, si interrompe non appena viene generata un'eccezione di questo tipo
Non gestita dall'utente: se selezionata, si interrompe solo se l'eccezione, di questo tipo, non viene gestita da un try / catch.

Potresti rimuovere il check in 'Thrown' per NullReferenceException che ti darà il vantaggio di non interrompersi ogni volta che il tuo sistema supera la riga in questione nel tuo codice, ma comunque di interrompersi se hai qualche aspettativa di NullReference non gestita che si verifica in altre parti del sistema.

— Lars Udengaard
fonte

3

L'aggiunta dell'attributo DebuggerStepThrough a un metodo in Visual Studio 2010 impedirà al debugger di arrestare un'eccezione non gestita generata dal metodo.

— Tim Murphy

Ho provato e non impedisce; si ferma ancora

— Shimmy Weitzhandler

1

@ Shimmy - Funziona per me! Assicurati di applicare DebuggerStepThrough a ciascun metodo dal punto in cui viene generato fino al punto in cui desideri che l'eccezione diventi visibile all'interno dello stack di chiamate. Se si cattura l'eccezione e la si gestisce all'interno della gerarchia delle chiamate in cui tutti i metodi sono decorati con DebuggerStepThrough, non si dovrebbe mai vedere un'interruzione VS su quell'eccezione.

— jpierson