Warum wird "log and throw" als Anti-Pattern angesehen? [geschlossen]

Diese Frage wurde durch eine Diskussion um diesen Artikel ausgelöst , auf die ich keine guten Antworten erhielt.

Warum sollte es eine schlechte Idee sein, Ihre Ausnahme zu protokollieren und dann erneut zu werfen (wobei natürlich die ursprüngliche Stapelverfolgung beibehalten wird), wenn Sie sie nicht anders behandeln können?

Ich nehme an, die Antwort liegt hauptsächlich darin, warum Sie sie fangen, wenn Sie damit nicht umgehen können. Warum nicht zulassen, dass jeder, der damit umgehen kann (oder wem keine andere Wahl bleibt, als damit umzugehen), es protokolliert, wenn er der Meinung ist, dass es protokollwürdig ist?

Wenn Sie es abfangen und protokollieren und erneut werfen, kann der Upstream-Code nicht erkennen, dass Sie die Ausnahme bereits protokolliert haben, sodass dieselbe Ausnahme möglicherweise zweimal protokolliert wird. Oder schlimmer noch, wenn der gesamte Upstream-Code demselben Muster folgt, wird die Ausnahme möglicherweise beliebig oft protokolliert, einmal für jede Ebene im Code, die beschließt, sie abzufangen, zu protokollieren und dann erneut zu werfen.

Einige könnten auch argumentieren, dass das Auslösen und erneute Werfen Ihrer Laufzeitleistung nicht hilft, da das Werfen und Abfangen von Ausnahmen relativ kostspielig ist. Es hilft Ihrem Code auch nicht in Bezug auf Prägnanz oder Wartbarkeit.

Log-and-Throw ist ein gutes Muster, wenn die Entität, die die Ausnahme abfängt und erneut auslöst, Grund zu der Annahme hat, dass sie Informationen enthält, die nicht weiter oben im Aufrufstapel protokolliert werden - zumindest nicht auf die am meisten gewünschte Weise. Dies kann aus mehreren Gründen auftreten:

1. Die Ausnahme kann an einer Grenze der Anwendungsebene abgefangen und erneut ausgelöst werden und privilegierte Informationen enthalten. Es wäre schlecht für eine Datenbankebene, eine Ausnahme zuzulassen, die besagt: "Versuch, dem Feld" Benutzer "einen doppelten Schlüssel" fnord "hinzuzufügen", um die äußere Anwendungsschicht zu erreichen (die sie wiederum einem Benutzer zugänglich machen könnte), aber dies Dies kann nützlich sein, wenn innere Teile der Datenbank eine solche Ausnahme auslösen und die Anwendungsschnittstelle sie abfängt, sicher protokolliert und eine etwas weniger beschreibende Ausnahme erneut auslöst.
2. Die Ausnahme kann eine sein, die die äußere Schicht wahrscheinlich ohne Protokollierung verarbeiten würde, aber die innere Schicht weiß möglicherweise etwas, was die äußere Schicht nicht weiß, was darauf hindeuten würde, dass die Protokollierung nützlich sein könnte. Als grobes Beispiel könnte eine mittlere Anwendungsschicht so programmiert werden, dass versucht wird, eine Verbindung zu einem Server herzustellen, und wenn dies nicht funktioniert, versuchen Sie es mit einem anderen. Das Überfluten des Anwendungsprotokolls mit Meldungen "Verbindung fehlgeschlagen", während ein Server wegen Wartungsarbeiten nicht verfügbar ist, ist möglicherweise nicht hilfreich, zumal aus Sicht der Anwendung alles einwandfrei funktioniert hat. Es kann nützlich sein, Informationen über den Verbindungsfehler an eine mit Servern verknüpfte Protokollierungsressource weiterzuleiten, die dann die Protokolle filtern kann, um einen Bericht darüber zu erstellen, wann der Server hoch und runter ging, im Gegensatz zu einem Protokoll jedes einzelnen Verbindungsversuchs .

Ich denke, der einfachste Grund ist, dass Sie normalerweise einen einzigen Top-Level-Handler haben, der dies für Sie erledigt, sodass Sie den Code mit dieser Ausnahmebehandlung nicht verschmutzen müssen.

Das Argument der Querschnittsthemen ist im Grunde, dass es Zeitverschwendung ist, Fehler zu behandeln, die Sie nicht betreffen. Es ist weitaus besser, den Fehler im Aufrufstapel aufblasen zu lassen, bis ein geeigneter Handler gefunden wurde.

Meiner Meinung nach sollten Sie nur dann eine Ausnahme abfangen, wenn Sie mit den Ergebnissen etwas Nützliches anfangen können. Es ist nicht sinnvoll, nur zu protokollieren, da Sie diese Arbeit weiter oben zentralisieren könnten.

IMO Log and Throw ist ein klarer Verstoß gegen das Prinzip der geringsten Überraschung.

Wenn die Ausnahme weiter oben im Aufrufstapel ordnungsgemäß behandelt wird, ist ein Fehlerprotokolleintrag möglicherweise überhaupt nicht wert. Und dann ist es verwirrend, einen Fehlerprotokolleintrag zu finden.