Wie sollen Ausnahmen auf architektonischer Ebene geplant werden?

Ich stimme halb Apocalisp's Kommentar zu. Instanzen von Exception sollten für Fälle reserviert sein, in denen ein Daten- oder Verarbeitungsfehler aufgetreten ist, aber durch Benutzer- oder Systemintervention wiederhergestellt werden können. Instanzen von RuntimeException sollten für Situationen reserviert sein, in denen keine Intervention innerhalb der Grenzen Ihrer Anwendung das Problem beheben kann. Diese beiden Typen werden daher als "Checked" - und "Unchecked" -Ausnahmen bezeichnet.

Ein Beispiel für ungeprüfte Ausnahmen wäre, wenn eine physische Ressource (z. B. eine Datenbank oder ein Nachrichtenbus) nicht verfügbar ist. Eine RuntimeException ist in diesem Fall gut, da Sie nicht planen, dass die Ressource nicht verfügbar ist. Daher muss Ihre Geschäftslogik nicht ständig nach DatabaseUnavailableException oder Ähnlichem suchen. Sie können RuntimeExceptions auf andere Weise behandeln (z. B. wenn AOP eine E-Mail sendet), um den Ausfall zu melden und Mitarbeiter oder Support das physische Problem beheben zu lassen.

Beispiele für geprüfte Ausnahmen wären eine schlechte Dateneingabe oder ein unvollständiger Datenzugriff oder etwas, das die Geschäftslogik tatsächlich nicht erfüllt, aber überprüft und wiederhergestellt werden kann. Ein Beispiel dafür könnte sein, dass ein gesuchter Benutzer nicht verfügbar ist. Es handelt sich um eine separate Bedingung in Ihrer Geschäftslogik, die überprüft und bearbeitet werden kann (z. B. durch den View-Teil Ihrer Anwendung, der die Nachricht der Exception als Fehlermeldung an den Benutzer meldet).

Viele Frameworks verwenden dieses Modell und es scheint besser zu funktionieren, als ich es bisher gesehen habe.

Davon abgesehen ersetzen viele die geprüften Ausnahmen durch zurückgegebene Nullen, -1, leere Zeichenfolge oder Number.MIN_VALUE. Das ist zwar in Ordnung, aber wenn Sie diese Werte nicht routinemäßig von einer Datenquelle oder Methode erwarten, sollte dies wahrscheinlich eine Ausnahme darstellen.

Ich finde im Allgemeinen, dass das Übersteuern über geprüfte Ausnahmen zu viel ist. Ausnahmen sollten für unerwartete Fehlerbedingungen reserviert werden, aus denen das Programm nicht vernünftigerweise wiederherstellen kann. Für diese stimme ich mit dem überein, was Sie beobachtet haben, dass spezielle Fehlertypen dazu neigen, ihre Bedeutung zu verlieren.

Generieren Sie als allgemeine Regel eine Ausnahme, wenn alle folgenden Bedingungen erfüllt sind:

• Die Bedingung kann nicht von hier wiederhergestellt werden.
• Es kann nicht erwartet werden, dass der Aufrufer von dieser Bedingung wiederhergestellt wird.
• Jemand wird die Situation debuggen wollen, damit er den Stack-Trace sehen kann.

Sie werden feststellen, dass der Typ der Ausnahme nicht wichtig ist und Sie java.lang.Error auch dann werfen können, wenn alle diese Bedingungen erfüllt sind. Wenn einer von ihnen falsch ist, dann ist wahrscheinlich eine Ausnahme übertrieben (brauchen Sie wirklich den Typ, die Nachricht und den Stack-Trace?)

Ziehen Sie stattdessen in Betracht, den Rückgabetyp der Methoden zu erweitern, um die erwarteten Fehlerarten anzugeben. Verwenden Sie beispielsweise einen Option & lt; A & gt; -Typ für Methoden, in denen er verwendet wird Es kann sinnvoll sein, in einigen Fällen keinen Wert zurückzugeben. Verwende einen Entweder & lt; A, B & gt; Typ für Methoden wo du möchtest müssen einen Wert zurückgeben, dessen Typ von Fehler oder Erfolg abhängt. Wo Sie vielleicht zuvor spezielle Exception-Subtypen hatten, können Sie stattdessen einfach entweder & lt; Fail, A & gt; wo Fail nur ein enum über die Arten von Fehlern ist, die erwartet werden.

Ich versuche sicherzustellen, dass die Anzahl der Orte, die try / finally verwenden, die Anzahl der Orte mit try / catch deutlich übersteigt. catch ist normalerweise reserviert für das Abfangen von Ausnahmen auf der obersten Ebene - wo sie sinnvoll behandelt werden können oder sich mit Ausnahmen von Plattform-APIs befassen.

In diesem Fall ist es kein großer Verlust, solange Sie Ausnahmen als sinnvolle Nachrichten angeben und Ausnahmen bei Bedarf ketten, wenn es nicht möglich ist, eine Ausnahme anhand ihrer Klasse zu identifizieren. Ich werfe oft RuntimeException, anstatt zu versuchen, eine Ausnahmeklasse für jeden erdenklichen Fehlerfall zu entwickeln - aber deine Meinung darüber hängt davon ab, wo du in der Debatte über die Checked vs Unchecked Exception sitzt.

"Effektives Java", 2nd. ed. Bloch hat in Kapitel 9 einige gute Ratschläge.

"Hardcore Java", Simmons , hat in Kapitel 5 einige gute Ratschläge.

Ich werde auch schamlos erwähnen, dass ich ein kleines Tool geschrieben habe, um Java-Quellcode zu verwalten. Ausnahmecode ist oft sehr redundant, alles, was Sie normalerweise interessieren, ist der Typ. Mein Tool akzeptiert eine Konfigurationsdatei, die Ausnahmetypen benennt und dann Code für diese Ausnahmen generiert.