Gestore di eccezioni non gestite in .NET 1.1

StackOverflow https://stackoverflow.com/questions/944

Domanda

Sto mantenendo un'applicazione .NET 1.1 e una delle cose che mi è stato assegnato è assicurarmi che l'utente non visualizzi notifiche di errori ostili.

Ho aggiunto gestori a Application.ThreadException E AppDomain.CurrentDomain.UnhandledException, che vengono chiamati.Il mio problema è che la finestra di dialogo di errore CLR standard è ancora visualizzata (prima che venga chiamato il gestore delle eccezioni).

Jeff parla di questo problema sul suo blog Qui E Qui.Ma non c'è soluzione.Qual è quindi il modo standard in .NET 1.1 per gestire le eccezioni non rilevate e visualizzare una finestra di dialogo intuitiva?

La risposta di Jeff è stata contrassegnata come corretta perché il collegamento fornito contiene le informazioni più complete su come eseguire ciò che è richiesto.

È stato utile?

Soluzione

Oh, in Windows Forms dovresti sicuramente riuscire a farlo funzionare.L'unica cosa a cui devi prestare attenzione sono le cose che accadono su thread diversi.

Ho un vecchio articolo di Code Project qui che dovrebbe aiutare:

Gestione delle eccezioni intuitiva

Altri suggerimenti

AppDomain.UnhandledException è un evento, non un gestore di eccezioni globali.Ciò significa che, nel momento in cui viene generato, l'applicazione è già in disuso e non c'è nulla che tu possa fare al riguardo, tranne che eseguire la pulizia e la registrazione degli errori.

Quello che è successo dietro le quinte è questo:Il framework ha rilevato l'eccezione, ha risalito lo stack di chiamate fino in cima, non ha trovato gestori in grado di ripristinarsi dall'errore, quindi non è stato in grado di determinare se fosse sicuro continuare l'esecuzione.Quindi, ha avviato la sequenza di spegnimento e ha avviato questo evento come cortesia nei tuoi confronti in modo che tu possa rendere omaggio al tuo processo già condannato.Ciò accade quando un'eccezione viene lasciata non gestita nel thread principale.

Non esiste una soluzione univoca a questo tipo di errore.È necessario inserire un vero gestore di eccezioni (un blocco catch) a monte di tutti i luoghi in cui si verifica questo errore e inoltrarlo (ad esempio) a un metodo/classe di gestione globale che determinerà se è sicuro semplicemente segnalare e continuare, in base a tipo e/o contenuto dell'eccezione.

Modificare:È possibile disabilitare (=hackerare) il meccanismo di segnalazione degli errori integrato in Windows in modo che la finestra di dialogo obbligatoria "crash and burn" non venga visualizzata quando l'app non funziona.Tuttavia, questo diventa efficace per Tutto le applicazioni nel sistema, non solo le tue.

Il comportamento delle eccezioni non gestite in un'applicazione Windows Forms .NET 1.x dipende da:

  • Il tipo di thread che ha generato l'eccezione
  • Se si è verificato durante l'elaborazione dei messaggi della finestra
  • Se un debugger era collegato al processo
  • L'impostazione del Registro di sistema DbgJitDebugLaunchSetting
  • Il flag jitDebugging in App.Config
  • Se hai sovrascritto il gestore delle eccezioni Windows Forms
  • Se hai gestito l'evento di eccezione del CLR
  • La fase lunare

Il comportamento predefinito delle eccezioni non gestite è:

  • Se l'eccezione si verifica nel thread principale durante il pompaggio dei messaggi della finestra, viene intercettata dal gestore delle eccezioni Windows Forms.
  • Se l'eccezione si verifica nel thread principale durante il pompaggio dei messaggi della finestra, il processo dell'app verrà terminato a meno che non venga intercettato dal gestore delle eccezioni Windows Forms.
  • Se l'eccezione si verifica in un thread manuale, di pool di thread o di finalizzatore, viene assorbita da CLR.

I punti di contatto per un'eccezione non gestita sono:

  • Gestore delle eccezioni di Windows Forms.
  • L'opzione del Registro di sistema per il debug JIT DbgJitDebugLaunchSetting.
  • Evento di eccezione non gestita CLR.

Per impostazione predefinita, la gestione delle eccezioni incorporata di Windows Form esegue le seguenti operazioni:

  • Rileva un'eccezione non gestita quando:
    • l'eccezione è sul thread principale e non è collegato alcun debugger.
    • si verifica un'eccezione durante l'elaborazione dei messaggi della finestra.
    • jitDebugging = false in App.Config.
  • Mostra la finestra di dialogo all'utente e impedisce la chiusura dell'app.

Puoi disabilitare quest'ultimo comportamento impostando jitDebugging = true in App.Config.Ma ricorda che questa potrebbe essere la tua ultima possibilità per interrompere la chiusura dell'app.Quindi il passaggio successivo per rilevare un'eccezione non gestita è la registrazione per l'evento Application.ThreadException, ad esempio:

Application.ThreadException += new
Threading.ThreadExceptionHandler(CatchFormsExceptions);

Prendere nota dell'impostazione del registro DbgJitDebugLaunchSetting in HKEY_LOCAL_MACHINE\Software.NetFramework.Questo ha uno dei tre valori di cui sono a conoscenza:

  • 0:mostra la finestra di dialogo dell'utente che chiede "debug o termina".
  • 1:lascia passare l'eccezione affinché CLR possa gestirla.
  • 2:avvia il debugger specificato nella chiave di registro DbgManagedDebugger.

In Visual Studio, vai al menu Utensili → Opzioni → Debug → JIT per impostare questo tasto su 0 o 2.Ma un valore pari a 1 è solitamente il migliore sul computer dell'utente finale.Si noti che questa chiave del Registro di sistema viene utilizzata prima dell'evento di eccezione non gestita CLR.

Quest'ultimo evento è la tua ultima possibilità di registrare un'eccezione non gestita.Viene attivato prima dell'esecuzione dei blocchi Finalmente.Puoi intercettare questo evento come segue:

AppDomain.CurrentDomain.UnhandledException += new
System.UnhandledExceptionEventHandler(CatchClrExceptions);

Si tratta di un'applicazione console o di un'applicazione Windows Form?Se si tratta di un'applicazione console .NET 1.1, purtroppo questo è dovuto alla progettazione: è confermato da uno sviluppatore MSFT nel secondo post del blog a cui hai fatto riferimento:

A proposito, sulla mia macchina 1.1 l'esempio di MSDN ha l'output previsto;è solo che la seconda riga non viene visualizzata finché non hai collegato un debugger (o meno).Nella versione 2 abbiamo invertito le cose in modo che l'evento UnhandledException si attivi prima che il debugger si colleghi, il che sembra essere ciò che la maggior parte delle persone si aspetta.

Sembra che .NET 2.0 lo faccia meglio (meno male), ma onestamente non ho mai avuto il tempo di tornare indietro e controllare.

È un'applicazione Windows Form.Le eccezioni rilevate da Application.ThreadException funzionano correttamente e non visualizzo la brutta casella delle eccezioni .NET (OK terminare, Annulla eseguire il debug?chi l’ha inventato??).

Ricevevo alcune eccezioni che non venivano rilevate e alla fine sono andato all'evento AppDomain.UnhandledException che causava problemi.Penso di aver rilevato la maggior parte di queste eccezioni e ora le sto visualizzando nella nostra bella casella di errore.

Quindi dovrò solo sperare che non ci siano altre circostanze che potrebbero impedire il rilevamento delle eccezioni da parte del gestore Application.ThreadException.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top