it-swarm.com.de

Best Practices zum Erstellen eines Fehlercode-Musters für ein Unternehmensprojekt in C #

Ich arbeite an einem Unternehmensprojekt, das in vielen KMUs und Unternehmen eingesetzt wird.
Die Unterstützung für dieses Projekt wäre schwierig und daher möchte ich ein Codierungsmuster für Fehler erstellen ( Wie HTTP-Statuscodes ). Auf diese Weise können Helpdesk-Mitarbeiter so schnell wie möglich auf Dokumente verweisen und die Probleme beheben.

Was sind die Best Practices und Empfehlungen dazu?
Jede Hilfe dazu ist hilfreich.

45
Pooya

Es gibt einen Unterschied zwischen Fehlercodes und Fehlerrückgabewerten. Ein Fehlercode ist für den Benutzer und den Helpdesk. Ein Fehlerrückgabewert ist eine Codierungstechnik, die angibt, dass in Ihrem Code ein Fehler aufgetreten ist.

Man kann Fehlercodes mit Fehlerrückgabewerten implementieren, aber ich würde davon abraten. Ausnahmen sind die moderne Methode, um Fehler zu melden, und es gibt keinen Grund, warum sie keinen Fehlercode enthalten sollten.

So würde ich es organisieren (Beachten Sie, dass die Punkte 2-6 sprachunabhängig sind):

  1. Verwenden Sie einen benutzerdefinierten Ausnahmetyp mit einer zusätzlichen Eigenschaft ErrorCode. Der Fang in der Hauptschleife meldet dieses Feld auf die übliche Weise (Protokolldatei/Fehler-Popup/Fehlerantwort). Verwenden Sie in Ihrem gesamten Code denselben Ausnahmetyp.
  2. Beginnen Sie nicht bei 1 und verwenden Sie keine führenden Nullen. Halten Sie alle Fehlercodes auf der gleichen Länge, damit ein falscher Fehlercode leicht erkannt werden kann. Ab 1000 ist normalerweise gut genug. Fügen Sie möglicherweise ein führendes "E" hinzu, um sie für Benutzer eindeutig identifizierbar zu machen (besonders nützlich, wenn der Support Desk Benutzer anweisen muss, den Fehlercode zu erkennen).
  3. Führen Sie eine Liste aller Fehlercodes, aber tun Sie dies nicht in Ihrem Code . Führen Sie auf einer Wiki-Seite eine kurze Liste für Entwickler, die sie leicht bearbeiten können, wenn sie einen neuen Code benötigen. Der Helpdesk sollte eine separate Liste in seinem eigenen Wiki haben.
  4. Versuchen Sie nicht, eine Struktur für die Fehlercodes zu erzwingen. Es wird immer schwer zu klassifizierende Fehler geben und Sie möchten nicht stundenlang darüber diskutieren, ob ein Fehler in der 45xx-Gruppe oder in der 54xx-Gruppe auftreten sollte. Sei pragmatisch.
  5. Weisen Sie jedem Wurf in Ihrem Code einen eigenen Code zu. Auch wenn Sie der Meinung sind, dass es sich um dieselbe Ursache handelt, muss der Helpdesk in verschiedenen Fällen möglicherweise unterschiedliche Aufgaben ausführen. Es ist für sie einfacher, "E1234: Siehe E1235" in ihrem Wiki zu haben, als den Benutzer dazu zu bringen, zu gestehen, was er falsch gemacht hat.
  6. Teilen Sie Fehlercodes auf, wenn der Helpdesk danach fragt. Eine einfache Zeile if (...) throw new FooException(1234, ".."); else throw new FooException(1235, ".."); in Ihrem Code spart möglicherweise eine halbe Stunde für den Helpdesk.

Und vergessen Sie niemals, dass der Zweck der Fehlercodes darin besteht, dem Helpdesk das Leben zu erleichtern.

70
Sjoerd

Sie müssen zuerst die Bereiche isolieren, in denen Fehler auftreten können und die für den Benutzer sichtbar sind. Dann können Sie sie dokumentieren. So einfach ist das.

Nun, theoretisch einfach. In der Praxis können überall Fehler auftreten, und wenn sie gemeldet werden, kann sich Nice Code in ein Monster aus Protokollierung, Auslösen und Behandeln von Ausnahmen und Übergeben von Rückgabewerten verwandeln.

Ich würde dann einen 2-Schritt-Ansatz empfehlen. Erstens ist zu protokollieren, viele und viele zu protokollieren.

Zweitens müssen Sie die Hauptkomponenten und ihre Schnittstellen bestimmen und definieren, in welchen Hauptfehlerfällen sich diese Komponenten befinden können. Sie können sich dann sichtbarer anmelden, wenn einer dieser Fehler auftritt (wie Sie den Fehler intern behandeln, liegt bei Ihnen - Ausnahmen oder Fehlercodes machen hier keinen Unterschied). Ein Benutzer wird dann im Allgemeinen den Fehler sehen und zu den Protokollen gehen, um detailliertere Informationen zu erhalten.

Der gleiche Ansatz wird für Webserver und Ihr http-Fehlercodebeispiel verwendet. Wenn der Benutzer einen 404 sieht und ihn dem Support meldet, sucht er in den Protokollen nach Details darüber, was los war, welche Seite wann besucht wurde, und holt sich alle anderen Informationen, die er kann, wo immer dies sinnvoll ist in der Datenbank, im Netzwerk oder in der Anwendung sein.

6
gbjbaanb

Ich würde für benutzerdefinierte Ausnahmen mit beschreibenden Namen und klaren Nachrichten gehen und diese werfen. Es ist viel einfacher, die vorhandene Ausnahmeinfrastruktur einer Sprache zu verwenden, als die Unterstützung für die Weitergabe und Interpretation von Fehlercodes einzubauen.

3
Stefan Billiet