Wie ordnen Sie Fehlercodes zu?

Wie identifizieren, erstellen und verwalten Sie bei der Entwicklung eines mittelgroßen Projekts Fehlercodes?

Ich kann mir für mein ganzes Leben keine einfache und saubere Methode dafür vorstellen. Einige meiner Ideen konvertieren Klassennamen und Methodennamen in eine Ganzzahlzeichenfolge, aber das ist viel zu lang, um dem Benutzer zusätzlich zu der Tatsache angezeigt zu werden, dass sich Methodennamen und Klassennamen möglicherweise ändern (hoffentlich nicht!). Andere verwenden lediglich ein inkrementierendes Protokollsystem (dh wenn ich eine neue Fehlermeldung erstelle, füge einfach 1 zur letzten Fehlernachrichten-ID hinzu). Aber das ist einfach völlig unorganisiert.

Um genauer zu sein, ich spreche über Fehlercode wie:

Error 401 Unauthorized.

Nein.

Fehlercodes sind ein Anachronismus. Sie stammen aus früheren Zeiten, als die Ausgabe sehr schwierig und kostspielig war, und die einzige Möglichkeit, einen Fehlerzustand zu signalisieren, war möglicherweise die Verwendung einer Reihe von Frontleuchten:

Heutzutage haben wir eine ausgereifte Ausnahmebehandlung, die in so ziemlich jeder gängigen Sprache eingebaut ist. Benutze es. Geben Sie die Benutzerinformationen an, mit denen sie arbeiten können. belästige sie nicht mit technischem Blabla, sondern erzähle ihnen grob, was schief gelaufen ist und was sie dagegen tun können. Geben Sie für die Protokollierung einfach die beschreibenden Namen Ihrer Ausnahmen ein und protokollieren Sie den Namen. Einfacher zu merken und auch einfacher mit grep oder ähnlichen Suchwerkzeugen zu finden.

Die Ausnahme ist natürlich, wenn Sie für Situationen programmieren, in denen die Ausgabe noch schwierig und teuer ist, z. B. für eingebettete Systeme oder Netzwerkprotokolle. HTTP verwendet nach wie vor numerische Antwortcodes, da diese äußerst einfach und effizient zu analysieren sind. In einigen Situationen kann das Lesen der ersten Ziffer bereits ausreichend sein, und Sie können den Rest des Pakets verwerfen.

Sie sollten überprüfen, wie Fehler- / Statuscodes in allgemeinen Protokollen wie HTTP organisiert sind . Sie reservieren unterschiedliche Bereiche für verschiedene Arten von Zuständen / Fehlern. Dies erleichtert es den Benutzern, einen unbekannten Statuscode zu identifizieren, und den Entwicklern, einen Code für eine neue Art von Fehler zuzuweisen, der zuvor nicht behandelt wurde.

Sorry, warum überhaupt Fehlercodes verwenden?
Fangen Sie die Ausnahme ab, protokollieren Sie sie und bieten Sie an, einen Bericht zu senden, wenn sich das Programm nicht wiederherstellen lässt .

(Angenommen, Ihre Sprache unterstützt Ausnahmen.)

Die einzige relevante Information, die Ihnen helfen könnte, den Fehler zu beheben, ist der Stack-Trace, den Sie nicht mit einem Fehlercode erhalten. (Ich gehe auch davon aus, dass Sie Fehlercodes für Fehlerberichte verwenden und sie nicht in das Gesicht eines Benutzers werfen möchten.)

Ich gehe von einem prozeduralen Kontext aus (C). Wenn Sie Objekte haben, ist ein Fehlerobjekt normalerweise besser, unabhängig davon, ob es sich um eine Ausnahme handelt oder nicht.

Sie sollten lokale Fehlercodes für jedes Modul verwenden. Für eine Bibliothek können Sie eine spezielle Kopfzeile mit den Fehlercodes 1, 2 usw. (oder -1, -2, wenn Sie dies vorziehen) haben. Stellen Sie sicher, dass Sie immer einen dieser Codes zurückgeben, z. B. errnoin Ihre eigenen Codes übersetzen. Wenn Sie mehrere Modulebenen haben, übersetzen Sie bei jedem Schritt (oder definieren Sie einen Bereich für den tieferen Fehler, z. B. die Werte 1001 - 1050 stammen von diesem anderen Modul).

Es ist auch wichtig, dass Sie ein Mittel zum Übersetzen des Codes in eine Zeichenfolge bereitstellen. Sie sollten niemals nur den Code melden, der nur zu Frust führt. Eigentlich sollte so ziemlich jeder Code in Ihrer Anwendung mit einer String-Übersetzungsfunktion ausgestattet sein. Zum Beispiel hat libc in der Regel strerrorund strsignal, aber leider fehlt strwaitstatus.