Fehlermeldung Text - Best Practices

Question

Wir sind ein Teil des Textes für unsere alte, schlecht geschriebenen Fehlermeldungen zu ändern. Was sind einige Ressourcen für Best Practices auf gute Fehlermeldungen zu schreiben (speziell für Windows XP / Vista).

Answer 1

Im Hinblick auf die Formulierung Ihrer Fehlermeldungen, empfehle ich für Windows-Anwendungen auf die folgenden Styleguides verweisen:

• Windows-User Experience Richtlinien und insbesondere der Abschnitt über Fehler Nachrichten hier .
• Microsoft Manual of Style

Answer 2

Die ultimative Best Practice ist der Benutzer verursacht Fehler in erster Linie zu verhindern.

Sie nichts Nutzer sagen, sie kümmern sich um nicht; Fehlercode 5064 nicht etwas für jeden bedeuten. Sagen Sie ihnen nicht tat sie etwas falsch; nicht zulassen es in erster Linie. Tadeln Sie sie nicht, vor allem nicht für Fehler der Software gemacht. Vor allem, wenn es ein Problem gibt, ihnen sagen, wie es zu beheben , so dass sie weitermachen können und einige Arbeit zu erledigen.

Answer 3

Eine gute Fehlermeldung sollte:

• Seien Sie unauffällig (kein Bluescreen oder gelb-Bildschirm des Todes)
• Geben Sie den Benutzer Richtung das Problem zu beheben (auf ihre eigenen, wenn möglich, oder die um Hilfe kontaktieren)
• Verstecken nutzlos, geheim Programmierer Unsinn (nicht sagen, „NULL-Verweis Ausnahme trat auf der Leitung 45“)
• Seien Sie deskriptive ohne ausführliche zu sein. Gerade genug Informationen, um den Benutzer zu sagen, was sie wissen müssen und nichts mehr.

Eine Sache, die ich angefangen habe zu tun, ist eine eindeutige Nummer zu erzeugen, die ich in der Fehlermeldung angezeigt und in die Protokolldatei schreiben, so kann ich den Fehler im Protokoll finden, wenn der Benutzer mir einen Screenshot oder Anrufe sendet und sagt „ich einen Fehler bekam. Er sagt, meine Referenznummer 0988-7634 ist“

Answer 4

Aus Sicherheitsgründen bieten keine internen Systeminformationen, dass der Benutzer nicht braucht.
Triviales Beispiel: wenn, um sich einzuloggen andernfalls nicht sagen, den Benutzer, wenn der Benutzername falsch ist oder das Passwort ist falsch; dies wird nur der Angreifer helfen, das System zu Brute-Force. Stattdessen einfach sagen: „Username / Passwort-Kombination ist ungültig“ oder so ähnlich.

Answer 5

Immer auch Vorschläge, um die Fehler zu beheben.

Answer 6

Versuchen Sie, einen Weg finden, um Ihre Software zu schreiben, so dass es das Problem für sie korrigiert.

Answer 7

Für jede Benutzereingabe (Strings, Dateinamen, Werte, etc.), zeigen immer den fehlerhaften Wert mit Begrenzungszeichen um ihn herum (Zitate, Klammern, usw.). z.

Der eingegebene Dateiname kann nicht gefunden werden: "somefile.txt"

Dies hilft dabei, alle Leerzeichen / Zeilenumbrüche zu zeigen, die in und stark haben schlich kann reduziert die Fehlersuche und Frustration.

Answer 8

1. Vermeiden identische Fehlermeldungen aus verschiedenen Orten kommen; parametrisieren mit Datei: Zeile, wenn möglich, oder anderen Kontext verwenden, mit dem Sie die Entwickler, eindeutig identifizieren, wo der Fehler aufgetreten ist
.
2. , um den Mechanismus-Design einfache Lokalisierung zu ermöglichen, vor allem wenn es sich um ein kommerzielles Produkt ist.
3. Wenn die Fehlermeldungen sind vom Benutzer sichtbar, machen sie vollständig, sinnvolle Sätze, die nicht intime Kenntnis des Codes übernehmen kann; denken Sie daran, Sie sind immer zu nah an das Problem - der Benutzer ist es nicht. Wenn möglich, gibt die Benutzerführung, wie zu verfahren, der, etc zu kontaktieren.
4. Es sollten alle Fehler haben eine Nachricht, wenn möglich; wenn nicht, dann versuchen und stellen Sie sicher, dass alle Fehler-Abroller Pfade schließlich eine Fehlermeldung erreichen, die Licht wirft auf das, was passiert ist.
   Ich bin sicher, es wird andere gute Antworten hier ...

Answer 9

Kürzere Meldungen können tatsächlich gelesen werden.

Je länger die Fehlermeldung, desto weniger wird der Benutzer lesen. Dass gesagt wird, versuchen Sie den Code Refactoring, so dass Sie Ausnahmen beseitigen kann, wenn es eine offensichtliche Antwort ist. Versuchen Sie, nur Ausnahmen, die auf Dinge außerhalb Ihrer Benutzer basierend happen oder Steuerung Ihres Codes.

Die beste Ausnahmemeldung ist, die Sie nie angezeigt haben.

Answer 10

Fehler Handhabung ist immer besser als Fehler Berichterstattung , aber da Sie die Fehlermeldungen nachrüsten und nicht unbedingt der Code hier ein paar Anregungen:

Die Anwender wollen Lösungen, keine Probleme. Helfen Sie ihnen, was nach einem Fehler zu tun, auch wenn die Nachricht so einfach wie „Bitte das aktuelle Fenster schließen und die Aktion wiederholen.“

Ich bin auch ein großer Fan von zentralisierte Protokollierung von Fehlern. Stellen Sie sicher, dass das Protokoll ist von Mensch und Computer scanbares. Benutzer nicht immer lassen Sie wissen, welche Probleme sie haben, besonders wenn sie ‚um gearbeitet‘ werden kann, so kann das Protokoll hilft Ihnen wissen, was die Dinge fixiert müssen.

Wenn Sie die Fehler leicht Dialogsteuerung, einen Dialog, die eine schöne, gut lesbare Nachricht mit einer Schaltfläche ‚Details‘ die Fehlernummer zu zeigen, Spur, usw. kann eine große Hilfe sein für Echtzeit-Problemlösung als gut.

Answer 11

Unterstützung für mehrere Sprachen für alle Arten von Nachrichten gilt, sondern neigt dazu, im Falle von Fehlermeldungen zu vergessen.

Answer 12

Ich würde sagen, zweiten die Benutzer nicht nutzlos esoterischen Informationen wie numerische Fehlercodes. Ich würde die Follow-up jedoch durch definitiv sagen, von technisch versierten Menschen für die Fehlersuche, diese Informationen zu protokollieren.