Ich habe mich gefragt, wie der allgemeine Konsens über Fehlermeldungen war. Wie detailliert sollten sie sein?
Ich habe an Projekten gearbeitet, wo es eine andere Fehlermeldung für die Eingabe einer Nummer gab, die zu groß war, zu klein war, eine Dezimalzahl hatte, eine Zeichenfolge war usw. Das war ziemlich nett für den Benutzer, da er genau wusste wo die Dinge liefen schief, aber der Code zur Fehlerbehandlung begann in der Größe mit der tatsächlichen Geschäftslogik zu konkurrieren und begann, einige seiner eigenen Fehler zu entwickeln.
Auf der anderen Seite habe ich an einem Projekt gearbeitet, wo Sie sehr allgemeine Fehler wie
bekommen würdenCOMPILE FAILED REASON 3
Was unnötig zu sagen ist, war fast völlig nutzlos, da sich Grund 3 als Linkfehler herausstellte.
Wo ist der Mittelweg? Woher weiß ich, ob ich beschreibende Fehlermeldungen hinzugefügt habe? Woher weiß ich, ob der Benutzer in der Lage sein wird, zu verstehen, wo die Fehler aufgetreten sind?
Es gibt zwei mögliche Zielgruppen für eine Fehlermeldung, den Benutzer und den Entwickler.
Im Allgemeinen sollte die Nachricht den Benutzer als Ziel haben.
o was ist die Ursache des Problems?
o warum das Programm das Problem nicht umgehen kann
o Was der Benutzer tun kann, um das Problem zu umgehen.
o wie man das Problem meldet.
Wenn das Problem gemeldet werden soll, sollte der Bericht so viele Programmkontextinformationen wie möglich enthalten.
o Modulname
o Funktionsname
o Zeilennummer
o Variablen von Interesse im allgemeinen Bereich des Problems
o vielleicht sogar ein Core Dump.
Richten Sie die richtige Zielgruppe aus.
Sie sollten mitteilen, was passiert ist und was die Optionen des Benutzers sind, in so wenigen Worten wie möglich. Je länger die Fehlermeldung ist, desto unwahrscheinlicher ist es, dass der Benutzer sie liest. Aus dem gleichen Grund sind kurze Fehlermeldungen kryptisch und nutzlos. Es gibt einen schönen Punkt in Bezug auf die Länge, und es ist für jede Situation anders.
Zu kurz:
Ungültige Eingabe.
Zu lang:
Geben Sie eine korrekt formatierte IP-Adresse ein, z. B. 192.168.0.1. Eine IP-Adresse ist eine Nummer, die zur Identifizierung Ihres Computers in einem Netzwerk verwendet wird.
Genau richtig:
Bitte geben Sie eine gültige IP-Adresse ein.
Was Code Bloat betrifft, wenn ein wenig zusätzlicher Code einen Benutzer daran hindert, Support anzurufen oder frustriert zu werden, dann ist es eine gute Investition.
Es gibt zwei Arten von Fehlermeldungen: Jene, die vom Benutzer gesehen werden und solche, die vom Programmierer gesehen werden.
"Woher weiß ich, ob der Benutzer verstehen kann, wo die Fehler aufgetreten sind?"
Ich gehe davon aus, dass diese Nachrichten nur vom Benutzer gesehen werden, und nicht eine sehr technische, und COMPILE FAILED REASON 3 ist keine typische Endbenutzer-Fehlermeldung. Es ist etwas, was der Programmierer sieht (der Benutzer kompiliert normalerweise keine Dinge).
Also, wenn es der Benutzer ist, der es sehen wird:
Schließe schließlich einige einfache und verständliche Befehle für den Benutzer ab ("Erneut versuchen", "Abbrechen", usw.).
Die eigentliche Frage zu Fehlermeldungen ist, ob sie überhaupt angezeigt werden sollen. Viele Fehlermeldungen werden einem Benutzer angezeigt, aber es gibt KEINE Möglichkeit, sie zu korrigieren.
Solange es einen Weg gibt, den Fehler zu korrigieren, geben Sie dem Benutzer genügend Informationen, die es ihm ermöglichen, ihn selbst zu korrigieren. Wenn sie es nicht selbst beheben können, gibt es einen Grund, ihnen den technischen Grund für den Absturz zu nennen? Nein, loggen Sie es nur zur späteren Fehlersuche in eine Datei ein.
So detailliert wie sie sein müssen;)
Ich weiß, es klingt wie eine kluge Antwort, aber so viel hängt von Ihrer Zielgruppe und der Art des Fehlers ab. Bei Fehlern, die durch eine ungültige Benutzereingabe verursacht werden, können Sie ihnen anzeigen, was einen gültigen Eintrag ausmacht. Für Fehler, die der Benutzer nicht kontrollieren kann, könnte eine generische Meldung "Wir arbeiten daran" ausreichen.
Ich stimme auch mit Jon Bs Kommentaren hinsichtlich der Länge überein.
Fehlermeldungen sollten detailliert, aber klar sein. Dies kann durch die Kombination von Fehlermeldungen aus mehreren Ebenen erreicht werden:
%Vor%Hier haben wir zwei Ebenen. Es kann mehr geben. Zuerst erzählen wir das große Bild und dann erzählen wir die Details. Die Reihenfolge ist so, dass wir zuerst den Teil verstehen, den die meisten verstehen, und dann den Teil, den die Leute weniger verstehen, aber beide können immer noch sichtbar sein.
Zusätzlich könnte es einen festen Vorschlag geben.
Ich würde auf der Seite von mehr Details irren, aber ich denke, dass Sie Ihre eigene Frage beantwortet haben. Um das Aufblähen im Code zu vermeiden, geben Sie nützliche Informationen in der Code / Fehlermeldung, aber Sie können mehr Details in der Dokumentation vielleicht oder mit Hilfe-Dateien oder FAQ geben.
zu wenig Informationen sind meiner Meinung nach schlimmer.
Wenn Sie eine Sprache mit reichhaltiger Introspektion oder anderen Fähigkeiten verwenden, wäre ein Protokoll mit der Zeile nützlich, die eine Prüfung nicht bestanden hat. Der Benutzer kann dann zum technischen Support weiterleiten oder auf andere Weise detaillierte Informationen erhalten. Dies ist kein zusätzlicher Code-Bloat, sondern die Verwendung von eigenem Code zur Bereitstellung von Informationen.
Tags und Links user-interface error-handling custom-errors