2014-02-27 16 views
14

Könnten Sie bitte erklären, ist es eine gute Idee, solchen Code zu schreiben oder nicht?Throw Ausnahme vs Protokollierung

try { 
     //my code here 
    } catch (Exception e) { 
     logger.error("Some error ", e); 
     throw new MyCustomException("Some error ", e); 
    } 

Sollte ich nur Logger oder bessere Option verlassen die "werfen" Konstruktion verlassen? Oder vielleicht die beste Idee, sie in der gleichen Zeit zu verwenden?

Ich verstehe, dass mit "throw" kann ich die Ausnahme in anderen Teil des Aufruf-Stack fangen, aber vielleicht zusätzliche Protokollierung hat einige versteckte Vorteile und es auch nützlich.

+0

Scheint mir gut, solange MyCustomException eine geprüfte Ausnahme ist. –

+0

danke jeder für Ihre Antworten! Sie haben mir sehr geholfen zu verstehen, wie man Protokollierung/Ausnahmebehandlung schreibt. – xrabbit

Antwort

4

Ich benutze beide in einigen Fällen, protokollieren und werfen die Ausnahme. Insbesondere ist es usufull in APIs. Indem wir die Ausnahme auslösen, erlauben wir dem Aufrufer, sie zu verarbeiten, und protokollieren, um die Ursache dafür zu identifizieren.

Und wenn der Aufrufer im selben System ist, dann, wenn wir in jedem Fang Logs hinzufügen, wird es doppelte Protokolle geben.

+1

Ich stimme @Kugathasan Abimaran. Ich arbeite gerade an einer API und muss meine Protokolldatei oft ruhig anschauen, wenn etwas schief geht. Gleichzeitig muss ich eine Exception werfen, um den Client zu benachrichtigen – crazyGuy

1

Ich denke, dass Sie das Muster mit Bedacht verwenden müssen. Wie Sie oben beschrieben haben, protokollieren Sie für jede Ausnahme 2 Stacktraces, die Ihre Logs mit exzessiven Informationen füllen können.

In Bezug auf Protokollierung gegen werfen, sind sie zwei getrennte Anliegen. Das Übergeben einer Ausnahme unterbricht die Ausführung, verhindert weitere Arbeiten, möglicherweise das Zurücksetzen von Datenbank-Commits usw. Die Protokollierung überträgt einfach Informationen in die Protokolldatei (oder anderswo). Es ist für das Debuggen von mehr Nutzen und oft viel schwieriger zu testen.

2

Wenn Sie das von Ihnen vorgeschlagene Muster verwenden, werden Fehlerereignisse normalerweise mehrfach im Protokoll gemeldet. Außerdem ist es nicht immer einfach, beim Lesen des Protokolls eine Verbindung zwischen ihnen herzustellen.

Persönlich bevorzuge ich Protokollierung von Fehlerereignissen nur einmal, und es in den höheren Anruf Ebenen tun. Daher melde ich mich fast nie & erneut zu werfen. Normalerweise lasse ich die Ausnahme den Call-Stack hinauf, bis es einen Kontext erreicht hat, in dem es irgendwie gehandhabt werden kann, und hier logge ich mich ein.

Wenn die Ausnahmen korrekt umgebrochen und neu geworfen werden, sollte der Kontext aus den Stack-Traces der einzelnen Protokollnachricht vollkommen klar sein.

2

Die richtige Antwort wäre: „es kommt“

Sie in der Regel wollen die Ausnahmen protokollieren, die Sie fangen, da sie zu entsprechen etwas falsch geht. Aus diesem Grund werden Codeanalyse-Tools wie Sonar Warnungen auslösen, wenn Sie sie nicht protokollieren.

Betrachten Sie die folgenden Aufgaben: Analysieren einer Datei. Beim Parsen der Datei versuchen Sie tatsächlich, jede Zeile zu analysieren. Manchmal sind einige Zeilen falsch formatiert, und Sie möchten deshalb die Analyse der Datei nicht unterbrechen. In diesem Fall möchten Sie wahrscheinlich nur die falsche Zeile protokollieren und die Datei weiter bearbeiten. Stellen Sie sich jedoch vor, dass Sie beim Lesen gelegentlich eine E/A-Ausnahme feststellen (z. B. löschte ein anderes Programm die Datei, während Ihre Datei darauf zugreift).

In diesem Fall möchten Sie wahrscheinlich den aufgetretenen Fehler protokollieren und eine neue Ausnahme auslösen, um die Verarbeitung der gesamten Datei zu stoppen.

Kurz gesagt, müssen Sie darüber nachdenken, was das Beste ist. Aber beide Praktiken sind nicht schlecht.

+1

+1 dafür, dass einige Dinge schief gehen, andere Dinge gehen * sehr * falsch, und der Unterschied ist der Schlüssel. – Rainbolt

6

Normalerweise würde ich argumentieren, dass Sie entweder oder wiederholen sollten.Beides führt dazu, dass jeder Layer die Ausnahmebedingung immer wieder protokolliert, wodurch die Logs schwer zu lesen sind. Schlimmer noch, es ist schwer herauszufinden, wie viele Fehler Sie tatsächlich haben - waren es sieben Fehler oder sieben Schichten der App, die den gleichen Fehler protokolliert haben?

Das bedeutet, dass , wenn Sie eine Ausnahme unterdrücken, Sie es protokollieren und sagen, warum Sie nicht dachten, es war es wert, erneut zu starten.

Auf der anderen Seite, wenn Sie werfen die Ausnahme, Sie wissen, es wird entweder gefangen und unterdrückt (in diesem Fall protokolliert der Catcher die Ausnahme und warum es unterdrückt wurde), oder es wird Blase aus Ihrer App heraus und werden vom App-Container abgefangen, der die Ausnahme abfängt und protokolliert. Jede Ausnahme wird nur einmal in den Protokollen angezeigt.

Verwandte Themen