c# - Nicht behandelter Ausnahmebehandler in .NET 1.1

Translate

Ich verwalte eine .NET 1.1-Anwendung und habe unter anderem die Aufgabe, sicherzustellen, dass dem Benutzer keine unfreundlichen Fehlerbenachrichtigungen angezeigt werden.

Ich habe Handler hinzugefügtApplication.ThreadExceptionundAppDomain.CurrentDomain.UnhandledException, die angerufen werden. Mein Problem ist, dass der Standard-CLR-Fehlerdialog weiterhin angezeigt wird (bevor der Ausnahmebehandler aufgerufen wird).

Jeff spricht in seinem Blog über dieses ProblemHierundHier. Aber es gibt keine Lösung. Wie wird in .NET 1.1 standardmäßig mit nicht erfassten Ausnahmen umgegangen und ein benutzerfreundliches Dialogfeld angezeigt?

Jeffs Antwort wurde als die richtige Antwort markiert, da der von ihm bereitgestellte Link die umfassendsten Informationen darüber enthält, wie das zu tun ist, was erforderlich ist.

This question and all comments follow the "Attribution Required."

Alle Antworten

Translate

Oh, in Windows Forms sollten Sie auf jeden Fall in der Lage sein, es zum Laufen zu bringen. Das einzige, worauf Sie achten müssen, sind Dinge, die in verschiedenen Threads passieren.

Ich habe hier einen alten Code Project-Artikel, der helfen sollte:

Benutzerfreundliche Ausnahmebehandlung

Quelle
Translate

AppDomain.UnhandledExceptionist einVeranstaltung, kein globaler Ausnahmebehandler. Dies bedeutet, dass sich Ihre Anwendung zum Zeitpunkt des Auslösens bereits im Abfluss befindet und Sie nichts dagegen tun können, außer Bereinigung und Fehlerprotokollierung.

Hinter den Kulissen ist Folgendes passiert: Das Framework hat die Ausnahme erkannt, den Aufrufstapel ganz nach oben verschoben, keine Handler gefunden, die sich von dem Fehler erholen würden, und konnte daher nicht feststellen, ob die Ausführung sicher fortgesetzt werden kann. Also hat es die Abschaltsequenz gestartet und dieses Ereignis aus Höflichkeit für Sie ausgelöst, damit Sie Ihrem bereits zum Scheitern verurteilten Prozess Ihren Respekt erweisen können. Dies geschieht, wenn eine Ausnahme im Hauptthread nicht behandelt wird.

Es gibt keine Einzelpunktlösung für diese Art von Fehler. Sie müssen einen echten Ausnahmebehandler (einen Catch-Block) vor allen Stellen platzieren, an denen dieser Fehler auftritt, und ihn an (z. B.) eine globale Handler-Methode / Klasse weiterleiten, die bestimmt, ob es sicher ist, einfach zu melden und fortzufahren, basierend auf Ausnahmetyp und / oder Inhalt.

Bearbeiten: Es ist möglich, den in Windows integrierten Fehlermeldemechanismus zu deaktivieren (= zu hacken), damit das obligatorische Dialogfeld "Absturz und Brennen" nicht angezeigt wird, wenn Ihre App ausfällt. Dies wird jedoch wirksam füralledie Anwendungen im System, nicht nur Ihre eigenen.

Quelle
Translate

Das nicht behandelte Ausnahmeverhalten in einer .NET 1.x Windows Forms-Anwendung hängt ab von:

  • Die Art des Threads, der die Ausnahme ausgelöst hat
  • Gibt an, ob es während der Verarbeitung von Fensternachrichten aufgetreten ist
  • Gibt an, ob ein Debugger an den Prozess angehängt wurde
  • Die Registrierungseinstellung DbgJitDebugLaunchSetting
  • Das jitDebugging-Flag in App.Config
  • Gibt an, ob Sie den Windows Forms-Ausnahmebehandler überschrieben haben
  • Gibt an, ob Sie das Ausnahmeereignis der CLR behandelt haben
  • Die Mondphase

Das Standardverhalten nicht behandelter Ausnahmen ist:

  • Wenn die Ausnahme beim Pumpen von Fensternachrichten im Hauptthread auftritt, wird sie vom Windows Forms-Ausnahmebehandler abgefangen.
  • Wenn die Ausnahme beim Pumpen von Fensternachrichten im Hauptthread auftritt, wird der App-Prozess beendet, sofern er nicht vom Windows Forms-Ausnahmebehandler abgefangen wird.
  • Wenn die Ausnahme bei einem Handbuch-, Threadpool- oder Finalizer-Thread auftritt, wird sie von der CLR verschluckt.

Die Kontaktstellen für eine nicht behandelte Ausnahme sind:

  • Windows Forms-Ausnahmebehandlungsroutine.
  • Der JIT-Debug-Registrierungsschalter DbgJitDebugLaunchSetting.
  • Das nicht behandelte CLR-Ausnahmeereignis.

Die in Windows Form integrierte Ausnahmebehandlung führt standardmäßig Folgendes aus:

  • Catches an unhandled exception when:
    • Ausnahme ist im Hauptthread und kein Debugger angehängt.
    • Ausnahme tritt während der Verarbeitung von Fensternachrichten auf.
    • jitDebugging = false in App.Config.
  • Zeigt dem Benutzer den Dialog und verhindert das Beenden der App.

Sie können das letztere Verhalten deaktivieren, indem Sie in App.Config jitDebugging = true festlegen. Denken Sie jedoch daran, dass dies möglicherweise Ihre letzte Chance ist, die App-Beendigung zu beenden. Der nächste Schritt zum Abfangen einer nicht behandelten Ausnahme ist die Registrierung für das Ereignis Application.ThreadException, z.

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 den Benutzerdialog mit der Frage "Debuggen oder Beenden".
  • 1: Lässt Ausnahmen für CLR durch.
  • 2: Startet den im Registrierungsschlüssel DbgManagedDebugger angegebenen Debugger.

Gehen Sie in Visual Studio zum MenüWerkzeugeOptionenDebuggenJITum diesen Schlüssel auf 0 oder 2 zu setzen. Ein Wert von 1 ist jedoch normalerweise am besten auf dem Computer eines Endbenutzers. Beachten Sie, dass dieser Registrierungsschlüssel vor dem nicht behandelten CLR-Ausnahmeereignis bearbeitet wird.

Dieses letzte Ereignis ist Ihre letzte Chance, eine nicht behandelte Ausnahme zu protokollieren. Es wird ausgelöst, bevor Ihre Endlich-Blöcke ausgeführt wurden. Sie können dieses Ereignis wie folgt abfangen:

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

Ist dies eine Konsolenanwendung oder eine Windows Forms-Anwendung? Wenn es sich um eine .NET 1.1-Konsolenanwendung handelt, ist dies leider beabsichtigt - dies wird von einem MSFT-Entwickler in derzweiter Blog-Beitrag, auf den Sie verwiesen haben:

Übrigens hat auf meinem 1.1-Computer das Beispiel von MSDN die erwartete Ausgabe; Es ist nur so, dass die zweite Zeile erst angezeigt wird, nachdem Sie einen Debugger angehängt haben (oder nicht). In Version 2 haben wir die Dinge umgedreht, sodass das UnhandledException-Ereignis ausgelöst wird, bevor der Debugger angehängt wird. Dies scheint das zu sein, was die meisten Leute erwarten.

Es hört sich so an, als ob .NET 2.0 dies besser macht (Gott sei Dank), aber ehrlich gesagt hatte ich nie Zeit, zurück zu gehen und nachzusehen.

Quelle
Ray
Translate

Es ist eine Windows Forms-Anwendung. Die Ausnahmen, die von Application.ThreadException abgefangen werden, funktionieren einwandfrei, und ich erhalte das hässliche .NET-Ausnahmefeld nicht (OKzu beenden,Stornierenzu debuggen? wer hat sich das ausgedacht ??).

Ich bekam einige Ausnahmen, die davon nicht erfasst wurden, und ging schließlich zum Ereignis AppDomain.UnhandledException, das Probleme verursachte. Ich glaube, ich habe die meisten dieser Ausnahmen abgefangen und zeige sie jetzt in unserer netten Fehlerbox an.

Ich muss also nur hoffen, dass es keine anderen Umstände gibt, die dazu führen würden, dass Ausnahmen nicht vom Application.ThreadException-Handler abgefangen werden.

Quelle