Grundlegende Regeln für gute Fehlermeldungen

Soeben musste ich bei der Integration einer Bibliothek mal wieder staunen. Die Bibliothek, auf die ich mich hier beziehe, zeichnet sich unter anderem durch einen guten Stil, eine durchgängige Dokumentation, sowie fast lückenlose Fehlerbehandlung aus. Deshalb ist es um so weniger verständlich, dass die eingesetzten Fehlermeldungen, die implementiert wurden, leider oft nicht aussagekräftig genug sind. Zusätzlich folgen die Fehlermeldungen keinem Schema. Sie erscheinen mir irgendwie schnell zusammengeschrieben (dieser Fehler wird im Übrigen oft begangen, wenn Fehlermeldungen im nachhinein schnell hinzugefügt werden!).

Man kann also hier schon feststellen:

Fehlermeldungen sind nur dann wirklich hilfreich, wenn diese von Anfang bis Ende, also von der Implementierung, bis hin zur Anzeige gut umgesetzt sind.

Man sollte diese so aussagekräftig wie möglich und so detailliert wie nötig gestalten. Hier ist ebenfalls zu unterscheiden welche Zielgruppe man adressiert. Beim Einsatz einer Bibliothek zur Herstellung einer gewissen Funktionalität, wäre die (erste) Zielgruppe, die Entwickler, die die Bibliothek einsetzen.

Folgende, einfache Regeln sollte man dabei beachten (ich beziehe mich hier lediglich auf den Inhalt der Fehlermeldungen – nicht die Stellen an denen, oder den Mechanismus mit dem, die Fehlermeldungen platziert werden), deshalb sollten die Fehlermeldungen:

  • einheitlich formatiert sein und somit ein einheitliches Erscheinungsbild haben
  • dem Schema: Fehler | Grund | [Auswirkung | Lösung] folgen, wobei Auswirkung und Lösung optional sind. Beispiel:
    Fehler: „Datei kann nicht erstellt werden'“, Grund: „Es existiert schon eine Datei mit diesem Namen“, Auswirkung: „Konfiguration konnte nicht gespeichert werden“, Lösung: „Bitte löschen Sie die bestehende Datei bevor sie diese Aktion wiederholen“
  • kurz, prägnant und wohl formuliert sein
  • der Zielgruppe entsprechend detailliert sein

Wenn man sich bei den Fehlermeldungen an diese simplen, grundlegenden Regeln hält, wird man feststellen, dass ein wichtiger Schritt in Richtung „gute Fehlermeldungen“ getan ist.

Habt ihr Ergänzungen zu den Regeln? Oder macht ihr es ganz anders und vielleicht sogar besser?
Dann nehmt doch an der Diskussion Teil und schreibt einen Kommentar.

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someone

3 Antworten zu “Grundlegende Regeln für gute Fehlermeldungen”

  1. Guido sagt:

    Dem Artikel kann ich nur zustimmen! Allerdings möchte ich auch noch eine kleine Ergänzung anbringen, die allerdings abhängig von der Art und Ebene der Fehlermeldung ist, dann aber auch auf Log-Meldungen und ggf. Exceptions übertragbar ist:
    [System | Komponente] |Fehler | Grund | [Auswirkung | Lösung]
    Bei Fehler oder Grund kann man ggf. noch den entsprechenden Parameter bzw. Aufruf hinzufügen, um eine spätere Analyse zu vereinfachen, dabei sollte man natürlich auf eine einheitliche Vorgehensweise achten. Bei Fehlermeldungen gegenüber dem Anwender macht die Anzeige aller oben genannter Bestandteile natürlich nicht immer Sinn, dort sollten Fehler und Grund allerdings immer vorkommen, System und Komponente sind dort in der Regel nicht anzuzeigen. Parameter bzw. Aufruf sollte man dem Anwender gegenüber nur dann anzeigen, wenn dies Sinn macht (Benutzereingaben) und diese nicht sicherheitsrelevant sind.

    • Hallo Guido,

      sicherlich hast du Recht, was den Detailgrad der Fehlermeldung angeht. Das sich das System (Komponente) noch zeigt und „man“ somit genau zuordnen kann, wo die Fehlermeldung entsprungen ist, habe ich einfach mal vorausgesetzt.

      Ich habe mich mit dem Artikel primär auf Fehlermeldungen bezogen, die einem User angezeigt werden, dieser User ist in der Regel der Endanwender, kann aber auch der Entwickler sein.

      Für den Endanwender werden Fehlermeldungen ja in der Regel reduziert und mit einer eindeutigen Nummer versehen. Für den Fall das man diesem Fehler nachgehen möchte, bleibt dann z.B. der Log im Idealfall mit genau den richtigen, also nicht zu viel und nicht zu wenig, Informationen (Stichwort: Stacktrace).

      Wichtig ist mir einfach dass, egal wie man vorgehen mag, der Weg einheitlich fortgeführt wird und man nicht hin- und herspringt. Stichwort: Konsistenz!

      Viele Grüße

      • Guido sagt:

        Hallo Ben,
        das sehe ich ja genau wie Du, ich wollte das in diesem Zusammenhang nur ergänzen, so dass sich dies auch auf eine noch allgemeinere Ebene übertragen lässt! „[..]die allerdings abhängig von der Art und Ebene der Fehlermeldung ist[…]“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.