Unbehandelte Exception Handler in .NET 1.1

stimmen
23

Ich bin die Aufrechterhaltung einer .NET 1.1-Anwendung und eines der Dinge, die ich beauftragt habe mit ist dafür, dass der Benutzer keine unfreundlichen Fehlermeldungen nicht sehen.

Ich habe hinzugefügt Handler Application.ThreadExceptionund AppDomain.CurrentDomain.UnhandledException, die aufgerufen tun bekommen. Mein Problem ist , dass der Standard - CLR Fehlerdialog weiterhin angezeigt wird (vor den Exception - Handler genannt).

Jeff spricht über dieses Problem in seinem Blog hier und hier . Aber es gibt keine Lösung. Also , was ist der normale Weg in .NET 1.1 nicht abgefangene Ausnahmen zu behandeln und ein freundliches Dialogfeld angezeigt werden ?

Jeffs Antwort wurde als die richtige Antwort markiert, weil der Link hat er vorgesehen, um die vollständigste Informationen darüber, wie zu tun, was erforderlich ist.

Veröffentlicht am 04/08/2008 um 02:15
quelle vom benutzer
In anderen Sprachen...                            


5 antworten

stimmen
11

Oh, in Windows Forms Sie sollten definitiv in der Lage sein, es zu bekommen zu arbeiten. Das einzige, was Sie zu achten haben, die Dinge in verschiedenen Threads geschieht.

Ich habe einen alten Code Project Artikel hier, die helfen sollen:

Benutzerfreundlich Exception Handling

Beantwortet am 04/08/2008 um 05:31
quelle vom benutzer

stimmen
5

Nicht behandelte Ausnahme Verhalten in einem .NET 1.x Windows Forms-Anwendung ist abhängig von:

  • Die Art der Thread, der die Ausnahme ausgelöst hat
  • Ob es trat während Fenster Nachrichtenverarbeitung
  • Ob ein Debugger wurde den Prozess angebracht
  • Die DbgJitDebugLaunchSetting Registrierungseinstellung
  • Die jitDebugging Flag in App.Config
  • Ob Sie overrode die Windows-Exception-Handler Forms
  • Ob behandeln Sie das Ausnahmeereignis CLR
  • Die Phase des Mondes

Das Standardverhalten von nicht behandelten Ausnahmen:

  • Wenn die Ausnahme auf dem Hauptthread tritt auf, wenn Fenstermeldungen Pumpen, ist es von der Windows Forms Exception-Handler abgefangen.
  • Wenn die Ausnahme auf dem Hauptthread tritt auf, wenn Fenstermeldungen Pumpen, wird es den App Prozess beenden, wenn es von der Windows Forms Exception-Handler abgefangen wird.
  • Wenn die Ausnahme tritt auf einem Handbuch, Thread oder Finalizerthread, wird es von der CLR geschluckt.

Die Berührungspunkte für eine nicht behandelte Ausnahme sind:

  • Windows Forms-Exception-Handler.
  • Der JIT-debug Registrierungsschalter DbgJitDebugLaunchSetting.
  • Die CLR nicht behandelte Ausnahmeereignis.

Die Windows Form Einbau-Ausnahmebehandlung hat standardmäßig folgende:

  • Fängt eine nicht behandelte Ausnahme, wenn:
    • Ausnahme ist am Haupt-Thread und kein Debugger befestigt.
    • Ausnahme tritt während Fenster Nachrichtenverarbeitung.
    • jitDebugging = false in App.Config.
  • Zeigt Dialog Benutzer und verhindert, dass App-Terminierung.

Sie können durch das Setzen jitDebugging = true in App.Config letzteres Verhalten deaktivieren. Aber denken Sie daran, dass dies Ihre letzte Chance sein kann App Kündigung zu beenden. So ist der nächste Schritt eine nicht behandelte Ausnahme ist die Registrierung für Ereignis Application.ThreadException zu fangen, zum Beispiel:

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

Beachten Sie die Registrierungseinstellung DbgJitDebugLaunchSetting unter HKEY_LOCAL_MACHINE \ Software.NetFramework. Dies hat einen von drei Werten, von denen ich weiß:

  • 0: zeigt Dialogbenutzer „debug oder beenden“ zu fragen.
  • 1: läßt Ausnahme durch für CLR zu behandeln.
  • 2: startet Debugger in DbgManagedDebugger Registrierungsschlüssel angegeben.

Gehen Sie in Visual Studio zum Menü ExtrasOptionenDebuggingJIT diesen Schlüssel auf 0 zu setzen oder 2. Aber ein Wert von 1 ist in der Regel am besten auf Endbenutzers Maschine. Beachten Sie, dass dieser Registrierungsschlüssel vor der nicht behandelte Ausnahme CLR Ereignis beaufschlagt.

Das letzte Ereignis ist Ihre letzte Chance, eine nicht behandelte Ausnahme loggt sein. Es wird ausgelöst, bevor Sie schließlich Blöcke ausgeführt haben. Sie können dieses Ereignis abfangen wie folgt:

AppDomain.CurrentDomain.UnhandledException += new
System.UnhandledExceptionEventHandler(CatchClrExceptions);
Beantwortet am 20/09/2008 um 16:52
quelle vom benutzer

stimmen
4

AppDomain.UnhandledException ist ein Ereignis , keine globalen Exception - Handler. Diese Mittel, durch die Zeit erhöht wird, ist die Anwendung bereits auf dem Weg den Bach runter, und es gibt nichts , was man dagegen tun kann, außer für die Bereinigung und Fehlerprotokollierung zu tun.

Was hinter den Kulissen passiert, ist dies: Der Rahmen erfasst die Ausnahme, ging den Call-Stack bis ganz nach oben, fand keine Behandlungsroutinen, die den Fehler beheben wäre, so war nicht in der Lage zu bestimmen, ob es sicher war, die Ausführung fortzusetzen. Also, es begann die Abschaltsequenz und feuert dieses Ereignis als Hilfestellung für Sie, damit Sie Ihre Beziehung zu Ihrem bereits verurteilt Prozess bezahlen können. Dies geschieht, wenn eine Ausnahme unhandled im Hauptthread gelassen wird.

Es gibt keine Single-Point-Lösung für diese Art von Fehlern. Sie müssen einen echten Ausnahmehandler (a catch-Block) vor allen Orten gebracht, wo dieser Fehler auftritt und leiten es an (zum Beispiel) eine globalen Handler-Methode / Klasse, die bestimmen, ob es sicher ist einfach zu berichten und weiterhin, bezogen auf Ausnahme-Typ und / oder Inhalt.

Edit: Es ist möglich (= Hack) das Fehlermeldemechanismus in dem Windows so die obligatorischen „Crash and Burn“ gebaut deaktivieren Dialog angezeigt nicht erhalten , wenn Sie Ihre App nach unten geht. Dies wird jedoch wirksam für alle Anwendungen im System, nicht nur Ihre eigenen.

Beantwortet am 04/08/2008 um 11:20
quelle vom benutzer

stimmen
3

Ist das eine Konsolenanwendung oder ein Windows Forms - Anwendung? Wenn es sich um eine .NET 1.1 - Konsole - Anwendung ist dies leider durch Design - es ist von einem MSFT dev in dem bestätigten zweiten Blogeintrag Sie verwiesen :

BTW, auf meiner 1.1 Maschine macht das Beispiel von MSDN die erwarteten Ausgabe hat; es ist nur, dass die zweite Zeile nicht angezeigt wird, bis Sie einen Debugger angeschlossen haben (oder auch nicht). In v2 haben wir die Dinge um umgedreht, so dass die UnhandledException Ereignis ausgelöst wird, bevor der Debugger Attaches, die, was erwarten die meisten Menschen zu sein scheint.

Es klingt wie .NET 2.0 tut dies besser (Gott sei Dank), aber ehrlich gesagt, ich hatte nie Zeit zurück zu gehen und zu überprüfen.

Beantwortet am 04/08/2008 um 03:45
quelle vom benutzer

stimmen
1

Es ist eine Windows Forms - Anwendung. Die Ausnahmen , die von Application.ThreadException gefangen arbeiten gut, und ich habe nicht die hässliche .NET Ausnahme Feld ( OKzu beenden, Cancelzu debuggen? , Die mit dem kam ??).

Ich war immer ein paar Ausnahmen, die nicht durch die gefangen wurde und am Ende zum AppDomain.UnhandledException Ereignisse gehen, die Probleme verursacht wurden. Ich glaube, ich habe die meisten dieser Ausnahmen gefangen, und ich sie in unserem schönen Errorbox jetzt angezeigt wird.

Also werde ich nur noch dort zu hoffen, sind nicht einige andere Umstände, die Ausnahmen würde dazu führen, nicht von der Application.ThreadException Handler abgefangen werden.

Beantwortet am 04/08/2008 um 03:54
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more