Visual Studio: come rompere le eccezioni gestite?

Vorrei che Visual Studio si interrompesse quando si verifica un’eccezione gestita (cioè non voglio solo vedere un messaggio di “Prima possibilità”, voglio eseguire il debug dell’eccezione effettiva).

ad esempio voglio che il debugger si interrompa all’eccezione:

try { System.IO.File.Delete(someFilename); } catch (Exception) { //we really don't care at runtime if the file couldn't be deleted } 

Ho trovato queste note per Visual Studio.NET:

1) In VS.NET accedere al menu Debug >> “Eccezioni …” >> “Eccezioni comuni del linguaggio di runtime” >> “Sistema” e selezionare “System.NullReferenceException”

2) Nella parte inferiore di quella finestra di dialogo c’è un “Quando viene lanciata l’eccezione:” casella di gruppo, seleziona “Interrompi nel debugger”

3) Esegui il tuo scenario. Quando viene lanciata l’eccezione, il debugger si fermerà e ti notificherà una finestra di dialogo che dice qualcosa come: “Un’eccezione di tipo” System.NullReferenceException “è stata lanciata. [Break] [Continua]”

Hit [Break]. Questo ti metterà sulla linea di codice che sta causando il problema.

Ma non si applicano a Visual Studio 2005 (non esiste l’opzione Eccezioni nel menu Debug ).

Qualcuno sa dove trova questa finestra di dialogo delle opzioni in Visual Studio che box ” Quando l’eccezione è generata “, con l’opzione ” Break into the debugger “?

Aggiornamento: il problema era che il mio menu Debug non aveva un elemento Eccezioni . Ho personalizzato il menu per aggiungerlo manualmente.

Con una soluzione aperta, vai all’opzione di menu Debug – Exceptions ( Ctrl + D , E ). Da lì puoi scegliere di rompere le eccezioni generate o non gestite dall’utente.

EDIT: la mia istanza è impostata con il “profilo” C # forse non è lì per altri profili?

C’è una finestra ‘eccezioni’ in VS2005 … prova Ctrl + Alt + E quando fai il debug e fai clic sulla casella di controllo ‘Gettato’ per l’eccezione su cui vuoi fermarti.

Mi ci è voluto un po ‘per trovare il nuovo posto per le impostazioni di attesa, quindi una nuova risposta.

Dal momento che Visual Studio 2015 controlla quali eccezioni devono essere interrotte nella finestra delle impostazioni di eccezione (Debug-> Windows-> Impostazioni eccezione).

Il modo più semplice per gestire le eccezioni personalizzate è selezionare “tutte le eccezioni non presenti in questo elenco”.

Controlla questo su msdn, spiega come impostarlo.

In sostanza, ecco i passaggi (durante il debug):

  1. Dal menu Debug, scegliere Eccezioni.

  2. Nella finestra di dialogo Eccezioni, selezionare Gettato per un’intera categoria di eccezioni, ad esempio, Eccezioni del Common Language Runtime.

    -o-

    Espandere il nodo per una categoria di eccezioni, ad esempio, Common Language Runtime Exceptions e selezionare Gettato per un’eccezione specifica all’interno di quella categoria.

Da Visual Studio 2015 in poi, è necessario andare alla finestra di dialogo “Impostazioni di eccezione” ( Ctrl + Alt + E ) e spuntare le “Eccezioni di runtime Common Language” (o una specifica che si desidera ad es. ArgumentNullException ) per renderla irrisolta gestite le eccezioni.

Passo 1 Passo 1 Passo 2 Passo 2

Una tecnica che uso è qualcosa come la seguente. Definisci una variabile globale che puoi utilizzare per uno o più blocchi di prova try a seconda di cosa stai tentando di eseguire il debug e utilizzare la seguente struttura:

 if(!GlobalTestingBool) { try { SomeErrorProneMethod(); } catch (...) { // ... Error handling ... } } else { SomeErrorProneMethod(); } 

Trovo che questo mi dà un po ‘più di flessibilità in termini di test perché ci sono ancora alcune eccezioni che non voglio che l’IDE interrompa.

La documentazione online sembra poco chiara, quindi ho appena eseguito un piccolo test. Se si sceglie di interrompere la procedura generata dalla finestra di dialogo Eccezioni, l’esecuzione del programma si interromperà su qualsiasi eccezione gestita o non gestita. Se si desidera interrompere solo le eccezioni gestite, sembra che l’unica risorsa sia quella di passare attraverso il codice e inserire i punti di interruzione su tutte le eccezioni gestite. Questo sembra un po ‘eccessivo, quindi potrebbe essere meglio aggiungere un’istruzione debug ogni volta che gestisci un’eccezione. Quindi quando vedi quell’output, puoi impostare un breakpoint su quella linea nel codice.