try - throwing exceptions c#




Gestore di eccezioni non gestito in.NET 1.1 (4)

Sto mantenendo un'applicazione .NET 1.1 e una delle cose a cui sono stato affidato è assicurarsi che l'utente non visualizzi notifiche di errore ostili.

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

Jeff parla di questo problema sul suo blog qui e qui . Ma non c'è soluzione. Quindi qual è il modo standard in .NET 1.1 per gestire le eccezioni non rilevate e visualizzare una finestra di dialogo amichevole?

La risposta di Jeff è stata contrassegnata come la risposta corretta, perché il link che ha fornito ha le informazioni più complete su come fare ciò che è richiesto.


AppDomain.UnhandledException è un evento , non un gestore di eccezioni globale. Ciò significa che, quando viene generato, l'applicazione è già in fase di esaurimento, e non c'è nulla che tu possa fare al riguardo, tranne che per 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 delle chiamate fino in cima, non ha trovato alcun gestore che si sarebbe ripristinato dall'errore, quindi non è stato in grado di determinare se fosse sicuro continuare l'esecuzione. Quindi, ha iniziato la sequenza di spegnimento e ha attivato questo evento come cortesia per voi in modo da poter rendere omaggio al vostro processo già condannato. Ciò accade quando un'eccezione viene lasciata non gestita nel thread principale.

Non esiste una soluzione a punto singolo per questo tipo di errore. È necessario mettere un vero gestore di eccezioni (un blocco catch) a monte di tutte le posizioni in cui si verifica questo errore e inoltrarlo (per esempio) a un metodo / classe globale di gestore che determinerà se è sicuro riportare e continuare semplicemente, in base a tipo di eccezione e / o contenuto.

Modifica: è possibile disabilitare (= hack) il meccanismo di segnalazione degli errori incorporato in Windows, in modo che la finestra di dialogo "crash e masterizzazione" obbligatoria non venga visualizzata quando l'app si arresta. Tuttavia, questo diventa efficace per tutte le applicazioni nel sistema, non solo per le proprie.


È un'applicazione Windows Form. Le eccezioni catturate da Application.ThreadException funzionano correttamente e non ottengo la brutta finestra delle eccezioni .NET ( OK per terminare, Annulla per eseguire il debug ?, chi è venuto fuori?).

Stavo ottenendo alcune eccezioni che non sono state prese da quello e finirono per andare all'evento AppDomain.UnhandledException che stava causando problemi. Penso di aver catturato la maggior parte di quelle eccezioni e le sto visualizzando nella nostra bella finestra di errore ora.

Quindi dovrò solo sperare che non ci siano altre circostanze che potrebbero far sì che le eccezioni non vengano catturate dal gestore Application.ThreadException.


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

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

User Friendly Exception Handling


Si tratta di un'applicazione console o di un'applicazione Windows Form? Se si tratta di un'applicazione di console .NET 1.1, questo è, purtroppo, di progettazione - è confermato da un dev di MSFT nel secondo post di blog cui si fa riferimento :

A proposito, sulla mia macchina 1.1 l'esempio da MSDN ha l'output atteso; è solo che la seconda riga non viene visualizzata fino a quando non hai collegato un debugger (o meno). Nella v2 abbiamo invertito le cose in modo che l'evento UnhandledException si attivi prima che il debugger si attachi, il che sembra essere quello che la maggior parte della gente 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.





exception-handling