Bewährte Methoden zum Erstellen eines Fehlercode-Musters für ein Unternehmensprojekt in C # [geschlossen]

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

Was sind die besten Praktiken und Empfehlungen, um dies zu tun?
Jede Hilfe dazu ist hilfreich.

c# programming-practices error-handling enterprise-development

— Pooya
quelle

Es gibt entweder zu viele mögliche Antworten, oder gute Antworten wären zu lang für dieses Format. Fügen Sie Details hinzu, um die Antwortmenge einzugrenzen oder ein Problem einzugrenzen, das in einigen Absätzen beantwortet werden kann. Und was hast du bisher versucht.

— Ben McDougall

Hängt davon ab, wie Ihr Unternehmen strukturiert ist. In C # haben wir dem Benutzer immer die Möglichkeit gegeben, uns das StackTrace zu mailen oder es aus den Fehlernachrichtendetails zu kopieren / einzufügen (wir hatten keine strengen Sicherheitsanforderungen).

— Falcon

Antworten:

Es gibt einen Unterschied zwischen Fehlercodes und Fehlerrückgabewerten. Ein Fehlercode ist für den Benutzer und den Helpdesk bestimmt. 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 Art, 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):

Verwenden Sie einen benutzerdefinierten Ausnahmetyp mit einer zusätzlichen ErrorCodeEigenschaft. Der Catch in der Hauptschleife meldet dieses Feld auf die übliche Weise (Protokolldatei / Fehler-Popup / Fehlerantwort). Verwenden Sie in Ihrem gesamten Code denselben Ausnahmetyp.
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 wird. Ab 1000 ist in der Regel gut genug. Fügen Sie möglicherweise ein vorangestelltes '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).
Führen Sie eine Liste aller Fehlercodes, tun Sie dies jedoch nicht in Ihrem Code . Halten Sie auf einer Wiki-Seite eine kurze Liste für Entwickler bereit, die sie einfach bearbeiten können, wenn sie einen neuen Code benötigen. Der Helpdesk sollte eine separate Liste in seinem eigenen Wiki haben.
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 liegen soll. Sei pragmatisch .
Weisen Sie jedem Wurf in Ihrem Code einen eigenen Code zu. Auch wenn Sie der Meinung sind, dass es sich um die gleiche Ursache handelt, muss der Helpdesk in verschiedenen Fällen möglicherweise unterschiedliche Aufgaben ausführen. Es ist einfacher für sie, "E1234: Siehe E1235" in ihrem Wiki zu haben, als den Benutzer dazu zu bringen, zu gestehen, was er falsch gemacht hat.
Teilen Sie die Fehlercodes auf, wenn Sie vom Helpdesk dazu aufgefordert werden. Durch eine einfache if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");Codezeile sparen Sie 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 .

— Sjoerd
quelle

Ich habe dies noch nie persönlich gemacht, aber häufig werden auch "Korrelations-IDs" angezeigt, fehlerinstanzspezifische Anleitungen, die dem Benutzer angezeigt und auch protokolliert werden. Auf diese Weise können Sie das genaue Auftreten von Fehlern in den Protokollen einfacher finden als mit einer ungefähren Zeit und einem Fehlercode.

— xdhmoore

Ich nehme an, es gibt wahrscheinlich eine Möglichkeit, den Fehlercode in die Korrelations-ID aufzunehmen, damit er als lesbarer Fehlercode für das Helpdesk und als Fehlerinstanz-ID für Entwickler verwendet werden kann.

— xdhmoore

Mein Muster ist ziemlich ähnlich. Aber anstelle von "E" habe ich einen kurzen Teil der App hinzugefügt. Unser Dokumentations-Framework kann zB eine Doc1234Weile die Main-App haben IrS1234. Meine Helpdesk-Mitarbeiter sind also ziemlich schnell dabei, meinen Benutzern zu helfen.

— Matthias Burger

Sie müssen zuerst die Bereiche eingrenzen, 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 das Melden von Fehlern kann netten Code in ein Monster aus Protokollierung, Ausnahmewurf und -behandlung und Übergabe von Rückgabewerten verwandeln.

Ich würde dann einen 2-Schritt-Ansatz empfehlen. Erstens ist zu protokollieren, viel und viel 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 vorliegt (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 in den Protokollen detailliertere Informationen finden.

Der gleiche Ansatz wird für Webserver und Ihr http-Fehlercodebeispiel verwendet. Wenn der Benutzer eine 404 sieht und diese dem Support meldet, sucht er in den Protokollen nach Details darüber, was gerade vor sich ging, welche Seite wann besucht wurde, und ermittelt alle anderen Informationen, die sinnvoll sind , in der DB, im Netzwerk oder in der Anwendung sein.

— gbjbaanb
quelle

Ich würde für benutzerdefinierte Ausnahmen mit beschreibenden Namen und klaren Botschaften 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.

— Stefan Billiet
quelle

Ich würde es begrüßen, wenn die Person, die diese Antwort von 1 auf 0 heruntergestuft hat, zumindest einen Grund nennen würde ...

— Stefan Billiet

Ich habe nicht downvotiert (nicht, dass es wichtig ist, darüber hinwegzukommen), aber ich denke, dass es auch in der Sprache Unterstützung für Rückgabewerte gibt.

— gbjbaanb

Es ist wichtig fuer mich; wenn ich mich irre, würde ich gerne wissen, damit ich lernen kann :-p Wie meinst du die bestehende Unterstützung für Rückgabewerte? Müssten Sie nicht ein Installationsprogramm schreiben, um einen normalen Rückgabewert von einem Fehlercode zu unterscheiden? Es ist eine Sache, eine Ausnahme in einen Fehlercode an der Grenze eines Systems zu übersetzen, aber davon wird generell abgeraten, sie in Ihrem System zu jonglieren. Ich glaube, der Pragmatic Programmer erwähnt solche Sachen.

— Stefan Billiet

Ausnahmen sind nicht in jedem Fall ein guter Mechanismus. Wenn Sie sich jedoch für die Verwendung von Fehlern entschieden haben, können Sie jedem Aufruf entweder einen out-Parameter hinzufügen oder wichtige Aufrufe alle einen Code zurückgeben lassen. Entscheide dich einfach von vornherein dafür und du bist golden. In der Praxis kommt es zu einer Mischung der beiden Fehlercodes an den Grenzen (Sie sind also nicht an eine einzige Sprache gebunden) und es werden intern Ausnahmen verwendet.

— gbjbaanb

Ich habe dich nicht runtergestimmt (nimm's leicht, sonst muss das jeder wiederholen :). Wenn Sie am Service Desk gearbeitet oder angerufen haben, ist es viel einfacher, nur eine kurze Nummer als eine Fehlermeldung zu übermitteln. Es ist garantiert, dass sich eine Fehlermeldung ändert, wenn sie mündlich übermittelt wird.

— Codism