Unbehandelter Ausnahmehandler in .NET 1.1

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

Frage

Ich verwalte eine .NET 1.1-Anwendung und habe unter anderem die Aufgabe, dafür zu sorgen, dass der Benutzer keine unfreundlichen Fehlermeldungen sieht.

Ich habe Handler hinzugefügt Application.ThreadException Und AppDomain.CurrentDomain.UnhandledException, die aufgerufen werden.Mein Problem ist, dass der Standard-CLR-Fehlerdialog immer noch angezeigt wird (bevor der Ausnahmehandler aufgerufen wird).

Jeff spricht in seinem Blog über dieses Problem Hier Und Hier.Aber es gibt keine Lösung.Was ist also die Standardmethode in .NET 1.1, um nicht abgefangene Ausnahmen zu behandeln und ein benutzerfreundliches Dialogfeld anzuzeigen?

Jeffs Antwort wurde als die richtige Antwort markiert, da der von ihm bereitgestellte Link die umfassendsten Informationen darüber enthält, wie die erforderlichen Maßnahmen zu ergreifen sind.

War es hilfreich?

Lösung

Oh, in Windows Forms sollten Sie es auf jeden Fall zum Laufen bringen können.Das Einzige, worauf Sie achten müssen, sind Dinge, die in verschiedenen Threads passieren.

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

Benutzerfreundliche Ausnahmebehandlung

Andere Tipps

AppDomain.UnhandledException ist ein Ereignis, kein globaler Ausnahmebehandler.Das bedeutet, dass Ihre Anwendung zum Zeitpunkt der Auslösung bereits den Bach runtergeht und Sie außer der Bereinigung und Fehlerprotokollierung nichts dagegen tun können.

Was sich hinter den Kulissen abspielte, ist Folgendes:Das Framework erkannte die Ausnahme, durchlief die Aufrufliste ganz nach oben, fand keine Handler, die den Fehler beheben konnten, und konnte daher nicht feststellen, ob die Fortsetzung der Ausführung sicher war.Also startete es die Abschaltsequenz und startete diese Veranstaltung als Gefälligkeit für Sie, 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 einheitliche Lö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 (zum Beispiel) an eine globale Handlermethode/-klasse weiterleiten, die anhand dessen bestimmt, ob es sicher ist, einfach zu melden und fortzufahren Ausnahmetyp und/oder Inhalt.

Bearbeiten:Es ist möglich, den in Windows integrierten Mechanismus zur Fehlerberichterstattung zu deaktivieren (=zu hacken), sodass das obligatorische Dialogfeld „Absturz und Brennen“ nicht angezeigt wird, wenn Ihre App ausfällt.Dies wird jedoch wirksam für alle die Anwendungen im System, nicht nur Ihre eigenen.

Das Verhalten unbehandelter Ausnahmen in einer .NET 1.x Windows Forms-Anwendung hängt von Folgendem ab:

  • Der Typ des Threads, der die Ausnahme ausgelöst hat
  • Ob es während der Fensternachrichtenverarbeitung aufgetreten ist
  • Ob ein Debugger an den Prozess angehängt wurde
  • Die DbgJitDebugLaunchSetting-Registrierungseinstellung
  • Das jitDebugging-Flag in App.Config
  • Ob Sie den Windows Forms-Ausnahmehandler überschrieben haben
  • 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-Ausnahmehandler abgefangen.
  • Wenn die Ausnahme beim Pumpen von Fensternachrichten im Hauptthread auftritt, wird der App-Prozess beendet, sofern er nicht vom Windows Forms-Ausnahmehandler abgefangen wird.
  • Wenn die Ausnahme in einem manuellen, Threadpool- oder Finalizer-Thread auftritt, wird sie von der CLR verschluckt.

Die Anlaufstellen für eine nicht behandelte Ausnahme sind:

  • Windows Forms-Ausnahmehandler.
  • Der JIT-Debug-Registrierungsschalter DbgJitDebugLaunchSetting.
  • Das von der CLR nicht behandelte Ausnahmeereignis.

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

  • Fängt eine nicht behandelte Ausnahme ab, wenn:
    • Die Ausnahme liegt im Hauptthread und es ist kein Debugger angeschlossen.
    • Bei der Verarbeitung von Fensternachrichten tritt eine Ausnahme auf.
    • jitDebugging = false in App.Config.
  • Zeigt dem Benutzer einen Dialog an und verhindert die Beendigung 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 Beendigung der App zu verhindern.Der nächste Schritt zum Abfangen einer nicht behandelten Ausnahme ist also die Registrierung für das Ereignis Application.ThreadException, z. B.:

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

Beachten Sie die Registrierungseinstellung DbgJitDebugLaunchSetting unter HKEY_LOCAL_MACHINE\Software.NetFramework.Dies hat einen von drei Werten, die mir bekannt sind:

  • 0:Zeigt einen Benutzerdialog mit der Frage „Debuggen oder Beenden“ an.
  • 1:Lässt eine Ausnahme durch, damit CLR damit umgehen kann.
  • 2:Startet den im DbgManagedDebugger-Registrierungsschlüssel angegebenen Debugger.

Gehen Sie in Visual Studio zum Menü Werkzeuge → Optionen → Debuggen → JIT um diese Taste auf 0 oder 2 zu setzen.Auf dem Computer eines Endbenutzers ist jedoch normalerweise der Wert 1 am besten.Beachten Sie, dass auf diesen Registrierungsschlüssel vor dem nicht behandelten CLR-Ausnahmeereignis reagiert 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);

Handelt es sich um eine Konsolenanwendung oder eine Windows Forms-Anwendung?Wenn es sich um eine .NET 1.1-Konsolenanwendung handelt, ist dies leider beabsichtigt – es wurde von einem MSFT-Entwickler in der bestätigt zweiter Blog-Beitrag, auf den Sie verwiesen haben:

Übrigens hat das Beispiel von MSDN auf meinem 1.1-Rechner tatsächlich die erwartete Ausgabe;Es ist nur so, dass die zweite Zeile erst angezeigt wird, nachdem Sie einen Debugger angehängt haben (oder auch nicht).In Version 2 haben wir die Dinge umgekehrt, sodass das UnhandledException-Ereignis ausgelöst wird, bevor der Debugger eine Verbindung herstellt, was anscheinend das ist, 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, noch einmal nachzusehen.

Es handelt sich um eine Windows Forms-Anwendung.Die Ausnahmen, die von Application.ThreadException abgefangen werden, funktionieren einwandfrei und ich erhalte nicht das hässliche .NET-Ausnahmefeld (OK zu beenden, Stornieren debuggen?Wer hat sich das ausgedacht??).

Ich erhielt einige Ausnahmen, die dadurch nicht abgefangen wurden, und landete schließlich beim AppDomain.UnhandledException-Ereignis, das Probleme verursachte.Ich glaube, ich habe die meisten dieser Ausnahmen erkannt und zeige sie jetzt in unserem schönen Fehlerfeld 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.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top