Was ist die beste Vorgehensweise zum Strukturieren von Ausnahmemeldungen?

Question

Wenn etwas in Ihrem Programm schief geht, können Sie eine Ausnahme in Ihrem Code mit einer Nachricht, die ein Problem beschreibt, auslösen. Typisches Beispiel:

throw new Exception("Houston we have a problem"); 

Ist es eine gute Übung, eine hardcoded Zeichenfolge in einen Ausnahmekonstruktor zu übergeben? Vielleicht sollte ich alle Ausnahmemeldungen an einem einzigen Ort halten. Bitte sagen Sie mir, was die beste Vorgehensweise ist, um ein Problem der Strukturierung von Ausnahmemeldungen zu lösen.

Answer 1

Wie Tim in den Kommentaren bereits erwähnt, kann die Lokalisierung ein Problem sein, wenn die Nachrichten den Benutzern angezeigt werden.

Was mein Ansatz zu diesem Thema ist, und was ich wirklich vorschlagen möchte, ist das Folgende.

Versuchen Sie es Generika zu machen.

Makea eine Konstanten Klasse Exception Nachrichten mit meaningfull Konstanten Namen wie diese halten:

public static const String IN_VARIABLE_MISSING = "An expected value is missing. Please try again"; 

Dies wird Ihnen die Möglichkeit geben, um tatsächlich die Ausnahme wieder zu verwenden, wo immer es gebraucht wird. (Sie müssen es auch nur an einer Stelle bearbeiten und überall aktualisieren.) Sie können einen Wrapper erstellen, der die Lokalisierung übernimmt. Aber es gibt so viele Möglichkeiten für dieses Thema, die ich nicht zu sehr ausführen werde.

So können Sie eine Ausnahme wie diese werfen:

throw new Exception(IN_VARIABLE_MISSING); 

Wenn diese Software ist, die kommerzielle verwendet werden soll ich würde auch eine eigene Exception zu schreiben, die erweitert die Standard-Exception empfehlen.

Warum?

Sie können eine Ausnahme erstellen, die Ihre Nachricht und eine Nummer zum Beispiel statt und wird über einen Schlüssel automatisch bauen für Sie dieses mögen:

IN-MODULE-NUMBER-IDENTIFICATION 

Sie sehen, wo das sehr nützlich sein könnte? Genau in der Lokalisierung und im schnelleren Finden, wo es passiert ist und warum es passiert ist.

Sie können es ändern, um IN am Anfang für interne Fehler zu schreiben. VA für Validierungsfehler. Dann die Klasse/Projekt, wo es passiert ist und dann eine Zahl oder was auch immer Sie wollen.

Dieses System bietet Ihnen auch die Möglichkeit, je nach dem vom Benutzer verwendeten Gebietsschema eine andere Zeichenfolge für diesen Schlüssel zu verwenden.

TL; DR Machen Sie es wiederverwendbar!

Answer 2

Ist es eine gute Übung, eine hardcoded Zeichenfolge in einen Ausnahmekonstruktor zu übergeben?

Ja und Nein.

Nein in dem Sinne, dass dieser Code:

throw new Exception("Houston we have a problem"); 

viel schwieriger für den Anrufer ist, zu beschäftigen. Das liegt daran, dass die Ausnahme nur durch den Text der Nachricht identifiziert wird; Daher muss ein Aufrufer, der Ausnahmen von Ihrem Code abfangen möchte (z. B. um nicht abzustürzen, aber wenn möglich weiterzufahren), Zeichenfolgenvergleiche durchführen, um herauszufinden, wo das Problem liegt.

z.B.

try 
{ 
    someService.DoSomething(sessionId) 
} 
catch(Exception ex) 
{ 
    if (ex.Message.Contains("Houston")) 
    { 
     //this indicates that someService couldn't connect to the database 
    } 
    else if(ex.Message.Contains("is on fire")) 
    { 
     //someService detected that the network is exploded 
    } 
    else{ 
    //we can only handle the two previous cases, all else is passed on} 
    throw;  
} 

Wie Sie sehen, dies wird chaotisch schnell, und wenn jemand ändert den Text ....

Jetzt diesen Code, auf der anderen Seite:

throw new SomethingSpecificWentWrongException(sessionId); 

wo SomethingSpecificWentWrongException könnte wie folgt aussehen:

public class SomethingSpecificWentWrongException: Exception 
{ 
    public int SessionId {get;protected set;} 
    public SomethingSpecificWentWrongException(int sessionId): 
    base($"Something specific went horribly wrong with session {sessionId}") 
    { 
    SessionId=sessionId; 
    } 
} 

kann leicht vom Anrufer behandelt werden:

try 
{ 
    someService.DoSomething(sessionId) 
} 
catch(SomethingSpecificWentWrongException ex) 
{ 
    //do whatever it is you do to recover from this 
} 
catch(SomethingElseSpecificWentWrongException wex) 
{ 
    //recover from this 
} 
else 
{ 
throw; 
} 

Sie werden feststellen, dass es ein hartcodierte-ish Zeichenfolge hier aber es ist durch die benutzerdefinierte Ausnahmeklasse selbst, nicht durch den Code im Besitz, den die Ausnahme zu werfen entscheidet; Dies macht einen großen Unterschied, weil Sie damit garantieren können, dass die Nachricht unabhängig davon, wo diese Ausnahme verwendet wird, vorhersehbar ist (hinsichtlich der Protokollierung usw.). Es ist also nicht nur einfacher, darüber nachzudenken, es ist viel wartbarer als hartkodierende Zeichenfolgen, die der Wurfcode liefert.