ErrorHandling-Klasse

Protokolliert bei (unbehandelten) Anwendungsfehlern viele für Entwickler hilfreiche Informationen in eine Datei (crash dump) und zeigt eine allgemeine Fehlermeldung an.

Archivierter Inhalt: Dieser Quelltext ist derzeit inaktiv und möglicherweise veraltet, nicht mehr gewartet oder funktioniert nicht mehr.

Diese Klasse wurde durch FieldLog ersetzt. FieldLog bietet eine umfassendere Fehlerbehandlung und eine deutlich ausführlichere Protokollierung von Ereignissen während der Anwendungsausführung, die eine schnellere und genauere Fehleranalyse ermöglichen. Es ist dabei einfacher zu integrieren, weil es mehr Aufgaben automatisch durchführt. Außerdem bietet es einen darauf abgestimmten Log-Betrachter.

Das Problem

Fehler treten immer wieder auf. Auch dann, wenn man am wenigsten damit rechnet. Solche Ausnahmefehler werden vom .NET-Framework ausgelöst und führen ohne Behandlung durch den Code oft zum sofortigen Ende der Programmausführung. In jedem Fall erscheint aber ein Hinweisfenster, das für den Anwender in den seltensten Fällen hilfreich ist. Es enthält je nach Umgebung entweder die technischen Details des Fehlers oder gar keine Informationen zum Fehler.

Auch für die Unterstützung durch den Entwickler ist das unpraktisch. Fragt er den Benutzer z. B. am Telefon oder per E-Mail danach, was denn passiert sei, erhält er oft keine genaue Beschreibung. Woher auch.

Die Lösung

Deutlich besser steht man dann da, wenn die genauen Umstände des Fehlers und die wichtigsten Angaben zur Ausführungsumgebung sofort in einer Datei gespeichert werden, die der Entwickler dann nur noch vom Anwender anzufordern braucht. In dieser Datei sind neben der Fehlermeldung und dem ausführlichen Stacktrace (auch für InnerExceptions und AggregateExceptions) bereits einige weitere Angaben wie das verwendete Betriebssystem, 32/64-Bit-Umgebung, Programmlaufzeit usw. enthalten, die die Fehlersuche erleichtern können.

Der Anwender erhält ein Dialogfenster angezeigt, das ihn über den unerwarteten Fehler informiert, eine kurze Fehlermeldung anzeigt (vielleicht hat er ja auch nur das falsche Verzeichnis ausgewählt), das Beenden oder (möglicherweise instabilere) Fortsetzen des Programms anbietet und den Ort der Protokolldatei nennt, um sie ggf. an den Entwickler zu senden.

Dieser Mechanismus kann auch dazu verwendet werden, um unkritische und behandelte Fehler zu protokollieren, ohne ein Fenster anzuzeigen. Zudem stehen Tracing-Methoden bereit, mit denen sich zur weiteren Analyse der Programmablauf nachvollziehen oder die Ausführungsdauer messen lässt, ohne einen Debugger zu verwenden.

Kompatibilität: .NET Ab Version 2.0

Beispiel

Wie die Fehlerberichterstattung in einer Windows-Forms- oder WPF-Anwendung integriert werden kann, ist in der Quelltext-Datei beschrieben. Hier der einzufügende Code für Windows-Forms-Anwendungen in der Datei Program.cs:

[STAThread]
static void Main()
{
    // MOD: Insert these 8 lines for global exception handling:
    //      (leave out the first 2 method calls for non-Windows-Forms applications)
#if !DEBUG
    // Add the event handler for handling UI thread exceptions to the event.
    Application.ThreadException +=
        new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
    // Set the unhandled exception mode to force all Windows Forms errors to go through
    // our handler.
    Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
    // Add the event handler for handling non-UI thread exceptions to the event.
    AppDomain.CurrentDomain.UnhandledException +=
        new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
#endif

    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run(new Form1());
}

// MOD: Insert these 2 methods for global exception handling:
//      (leave out the first method for non-Windows-Forms applications)
static void Application_ThreadException(
    object sender,
    System.Threading.ThreadExceptionEventArgs e)
{
    ErrorHandling.ReportException(
        e.Exception,
        "Application.ThreadException");
}

static void CurrentDomain_UnhandledException(
    object sender,
    UnhandledExceptionEventArgs e)
{
    ErrorHandling.ReportException(
        e.ExceptionObject as Exception,
        "AppDomain.UnhandledException");
}

In WPF-Anwendungen ist dieser Code in der Datei App.xaml.cs einzufügen:

// Add the contents of the App class constructor if it is already there.
public App()
{
#if !DEBUG
    DispatcherUnhandledException += App_DispatcherUnhandledException;
    AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;
#endif
}

private void App_DispatcherUnhandledException(
    object sender,
    System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
    ErrorHandling.ReportException(
        e.Exception,
        "DispatcherUnhandledException");
    e.Handled = true;
}

private void CurrentDomain_UnhandledException(
    object sender,
    UnhandledExceptionEventArgs e)
{
    ErrorHandling.ReportException(
        e.ExceptionObject as Exception,
        "AppDomain.UnhandledException");
}

Download

ErrorHandling.cs16,3 KiBQuelltext der ErrorHandling-Klasse

Hinweise zur Verwendung

Zur Verwendung der ErrorHandling-Klasse wird die MyEnvironment-Klasse benötigt.

Lizenz und Nutzungsbedingungen

Diese Software wird unter den Bedingungen der vereinfachten BSD-Lizenz veröffentlicht. Die genauen Lizenzbedingungen befinden sich im Download.

Statistische Daten

  • Erstellt am 2009-06-01, aktualisiert am 2012-10-08.
  • Ca. 380 Codezeilen, geschätzte Ent­wick­lungs­kos­ten: 380 - 1 500 €