Interruzione di Visual Studio 2015 per eccezioni non gestite non funzionanti

Visual Studio aveva una casella di controllo specifica per "Interrompi in caso di eccezione non gestita". Nel 2015 questo è stato rimosso (o spostato da qualche parte non riesco a trovarlo). Quindi ora i miei progetti convertiti non si interrompono più se non riesco a fornire un gestore di eccezioni a livello utente. Non voglio interrompere tutte le "eccezioni lanciate" perché gestisco quelle specifiche. Proprio dove non riesco a fornire un gestore specifico.

In questo momento il mio codice esce semplicemente dalla procedura corrente e continua l'esecuzione nella posizione dello stack di chiamate successivo, NON BUONO.

Qualcuno sa come riaverlo in Visual Studio 2015? Ieri sono passato all'edizione della community.

C'è una nuova finestra chiamata "Impostazioni eccezione" che appare per impostazione predefinita nel riquadro in basso a destra quando si avvia il debug. Ha tutte le opzioni che ti aspetteresti.

Puoi sollevarlo con CTRL+ ALT+E

Ciò ti consente di scegliere quali eccezioni causano un'interruzione nel debugger.

La chiave, tuttavia, è che puoi anche impostare se queste eccezioni si interrompono sempre o solo quando si tratta di un'eccezione non gestita, ma l'impostazione non è molto intuitiva.

Dovrai prima selezionare "Abilita solo il mio codice" in Strumenti> Opzioni> Debug.

Ciò consente quindi di fare clic con il pulsante destro del mouse sull'intestazione della colonna (Interrompi quando viene generata) nella nuova finestra Impostazioni eccezioni e aggiungere la colonna "Azioni aggiuntive", che quindi consente di impostare ciascuna eccezione come "Continua se non gestita nel codice utente".

Quindi fai clic con il pulsante destro del mouse su un'eccezione o su un intero gruppo e disabilita il flag "Continua se non gestito nel codice utente". Sfortunatamente, la colonna "Azioni aggiuntive" apparirà vuota, il che equivale a "Interrompi se non gestita nel codice utente".

Maggiori informazioni su questo qui:

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

Ho avuto lo stesso problema e sono riuscito a risolverlo in questo modo -

1. Premere Ctrl+ Alt+ eper visualizzare la finestra Impostazioni eccezioni .
2. Selezionare Eccezioni Common Language Runtime .

Questo è tutto!

Questo post mi ha ispirato poiché utilizzo una versione x64 di Windows .

Per i googler che vogliono interrompere solo quando l'eccezione riguarda il loro codice, c'è un'opzione in Visual Studio 2015: Opzioni-> Debug-> Generale-> Solo il mio codice. Una volta verificato, consente di non interrompersi quando l'eccezione viene gestita (lanciata e rilevata) al di fuori del codice.

Microsoft ha leggermente modificato la logica nella nuova finestra delle eccezioni.

Vedi http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

La parte fondamentale è:

Note importanti

• Questa nuova finestra contiene tutte le stesse funzionalità della vecchia finestra di dialogo modale. Nessuna funzionalità del debugger è cambiata solo il modo in cui è possibile accedervi
• Il debugger si interromperà sempre quando un'eccezione non viene gestita
• L'impostazione da modificare se il debugger interrompe le eccezioni non gestite dall'utente è stata spostata in un menu di scelta rapida
• La posizione del menu è stata spostata in Debug -> Windows -> Impostazioni eccezione

Tuttavia , se come me hai un gestore delle eccezioni non gestite globale nel tuo codice, il secondo elemento in quell'elenco è la chiave: per me, nessuna eccezione sarà quindi veramente non gestita, il che sembra essere diverso da VS2013.

Per ripristinare il comportamento in cui VS interrompe le eccezioni non gestite, ho dovuto selezionare tutti i tipi di eccezione per i quali volevo interrompere e quindi assicurarmi in secondo luogo che le "Opzioni aggiuntive" (potrebbe essere necessario rendere visibile questa colonna *) per "Continua quando non gestito nel codice utente " NON è stato impostato. La logica di VS2015 non sembra considerare il mio gestore di eccezioni non gestito globale "gestito nel codice utente", quindi si interrompe su questi; però non si rompe sulle eccezioni catturate. Questo lo fa funzionare come ha fatto VS2013.

* Come abilitare la colonna "Azioni aggiuntive"

Se sto leggendo correttamente tra le righe qui, il problema è che la tua eccezione sta effettivamente "scomparendo" anche se il comportamento del debugger predefinito dovrebbe interrompersi in caso di eccezioni non gestite.

Se si dispone di metodi asincroni, è possibile che si verifichi questo problema perché le eccezioni non rilevate in un thread del pool di thread come parte di una continuazione dell'attività non sono considerate eccezioni non gestite. Piuttosto, vengono inghiottiti e archiviati con l'attività.

Ad esempio, dai un'occhiata a questo codice:

class Program
{
    static void Main(string[] args)
    {
        Test();
        Console.ReadLine();
    }

    private async static Task Test()
    {
        await Task.Delay(100);
        throw new Exception("Exception!");
    }
}

Se esegui questo programma con le impostazioni predefinite del debugger (interrompi solo le eccezioni non gestite), il debugger non si interromperà. Ciò è dovuto al fatto che il thread del pool di thread allocato alla continuazione ingoia l'eccezione (passandola all'istanza di Task) e si rilascia nuovamente nel pool.

Nota che, in questo caso, il vero problema è che il Taskrestituito da Test()non viene mai controllato. Se hai tipi simili di logica "spara e dimentica" nel tuo codice, non vedrai le eccezioni nel momento in cui vengono lanciate (anche se sono "non gestite" all'interno del metodo); l'eccezione compare solo quando si osserva l'attività in attesa, verificando il suo risultato o osservando esplicitamente la sua eccezione.

Questa è solo un'ipotesi, ma penso che probabilmente stai osservando qualcosa di simile.

Nella mia esperienza, le impostazioni delle eccezioni nel 2015 vengono completamente sbalordite se si modifica qualcosa.

Aspettatevi che se fino al gruppo genitore "CLR" non dovreste ricevere alcuna esecuzione di rottura per non gestito. Ti interromperai sempre se un'eccezione non viene gestita. Ma, se hai deselezionato il gruppo CLR, il codice all'interno di un try ... catch semplicemente non dovrebbe causare un'interruzione. Questo non è il caso.

Soluzione: nella nuova casella degli strumenti delle impostazioni delle eccezioni, fare clic con il pulsante destro del mouse e scegliere "Ripristina impostazioni predefinite". Taadaaaa ... Si comporta di nuovo normalmente. Ora non fottere.

Prova a seguire le istruzioni:

1. Nella finestra Impostazioni eccezioni, apri il menu di scelta rapida facendo clic con il pulsante destro del mouse nella finestra e quindi selezionando Mostra colonne. (Se hai disattivato Just My Code, non vedrai questo comando.)
2. Dovresti vedere una seconda colonna denominata Azioni aggiuntive. Questa colonna visualizza Continua se non gestita dal codice utente su eccezioni specifiche, il che significa che il debugger non si interrompe se l'eccezione non viene gestita nel codice utente ma viene gestita nel codice esterno.
3. È possibile modificare questa impostazione per un'eccezione particolare (selezionare l'eccezione, fare clic con il pulsante destro del mouse e selezionare / deselezionare Continua se non gestita nel codice utente) o per un'intera categoria di eccezioni (ad esempio, tutte le eccezioni di Common Language Runtime).

https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx

È tutto un po 'confuso, e secondo me non è buono come la vecchia finestra di dialogo delle eccezioni, ma comunque.

Se un'eccezione è nell'elenco e spuntata, il debugger si interromperà ogni volta che viene generata l'eccezione.

Se un'eccezione è deselezionata o non è presente nell'elenco, il debugger si interromperà solo quando quel tipo di eccezione non è gestito dall'utente.

Ad esempio, nello screenshot seguente, il debugger si interromperà ogni volta che System.AccessViolationExceptionviene lanciato a, ma per tutte le altre eccezioni si interromperà solo se l'eccezione non è stata gestita dall'utente.

Quando sono passato a VS2015, ho riscontrato anche problemi in cui le eccezioni "interrompevano" l'applicazione, ma ora vengono ignorate e passate immediatamente. Ci sono momenti in cui vogliamo che il nostro codice lanci intenzionalmente eccezioni nei punti in cui vogliamo che il codice si fermi, piuttosto che continuare. Usiamo sempre la frase Throw New Exception("Message")per far sì che il nostro codice si interrompa intenzionalmente:

    If SomethingReallyBad = True Then
        Throw New Exception("Something Really Bad happened and we cannot continue.")
    End If

Con VS2015, il classico "System.Exception" è ciò che viene lanciato quando diciamo Throw New Exception. Pertanto, dovevamo controllare il segno di spunta "System.Exception" nelle nuove impostazioni di eccezione:

Seleziona la casella System.Exception

Una volta controllato, il nostro codice ha funzionato come previsto.

La soluzione a questo è semanticamente l'opposto di ciò che pensi di impostare. È necessario assicurarsi che Continua quando non gestita nel codice utente è non abilitato cioè non controllati come indicato sotto l'Azioni aggiuntive colonna nella Eccezione impostazioni scheda - vedi sotto:

stai effettivamente dicendo di non continuare (cioè interrompere) quando non è gestito nel codice

Per fare questo:

1. Fare clic con il pulsante destro del mouse sull'eccezione o sulla serie di eccezioni che ti interessano (ad esempio, di solito la riga superiore "Eccezioni di Common Language Runtime" nell'albero)
2. Seleziona l'opzione Continua se non gestita nel codice utente (vedi sotto)
3. Assicurati che le eccezioni non siano selezionate (vedi sotto)
4. continuare il debug

Questo ha funzionato per me - di nuovo felice.

Questo era in VS 2015

C'è sicuramente un bug in Visual Studio che può bloccarlo richiedendo un riavvio. Anche VS2015.

Ho avuto una singola situazione a thread in cui a NullReferenceExceptionveniva catturato da un gestore "esterno" (ancora nel mio codice) anche se avevo chiesto che si interrompesse quando veniva sollevato.

Mi rendo conto che questa è un'eccezione "gestita" e stai parlando di un'eccezione "non gestita", tuttavia sono abbastanza sicuro che a volte un rapido riavvio di VS risolverà questo problema, se IISRESET non lo fa.

Visual Studio 2017 funziona perfettamente con la gestione degli errori. Visual Studio 2015 d'altra parte fa schifo nella gestione degli errori con le attività perché in modalità di debug vengono rilevate tutte le eccezioni che si verificano in un'attività asincrona, ma se lo passo sopra si blocca indefinitamente. Se eseguito senza debug si blocca a tempo indefinito senza eccezioni catturate !!! Amo lo studio visivo e lo uso dal 1995 e il 2015 è di gran lunga la versione peggiore, anche se sono passato direttamente dal 2010 al 2015. Ho passato 8 ore cercando di far funzionare questa gestione delle eccezioni senza successo. Ho copiato il codice esatto nel 2017 sul mio computer di casa e ha funzionato perfettamente. Sono molto irritato dal fatto che Microsoft abbia inserito le attività in un framework che il compilatore 2015 non può gestire correttamente.