Es gibt einige Regeln für die Ausnahmebehandlung, die Sie berücksichtigen sollten. Zunächst müssen Sie jedoch berücksichtigen, dass Ausnahmen Teil der vom Code bereitgestellten Schnittstelle sind . dokumentieren sie . Dies ist natürlich besonders wichtig, wenn es sich um eine öffentliche Schnittstelle handelt, aber auch bei privaten Schnittstellen ist dies eine sehr gute Idee.
Ausnahmen sollten nur an dem Punkt behandelt werden, an dem der Code etwas Sinnvolles damit anfangen kann. Die schlechteste Handhabungsoption besteht darin, überhaupt nichts dagegen zu unternehmen, was nur getan werden sollte, wenn dies genau die richtige Option ist. (Wenn ich eine solche Situation in meinem Code habe, füge ich einen entsprechenden Kommentar hinzu, damit ich mir keine Sorgen um den leeren Körper machen muss.)
Die zweitschlechteste Option besteht darin, eine nicht verwandte Ausnahme auszulösen, ohne dass das Original als Ursache beigefügt ist. Das Problem hierbei ist, dass die Informationen innerhalb der ursprünglichen Ausnahme, die die Diagnose des Problems ermöglichen würden, verloren gehen. Sie erstellen etwas, mit dem niemand etwas anfangen kann (außer sich darüber zu beschweren, dass „es nicht funktioniert“ und wir alle wissen, wie wir diese Fehlerberichte hassen ).
Viel besser ist es, die Ausnahme zu protokollieren. Auf diese Weise kann jemand herausfinden, wo das Problem liegt, und es beheben. Sie sollten die Ausnahme jedoch nur an dem Punkt protokollieren, an dem sie sonst verloren gehen oder über eine externe Verbindung gemeldet werden würde. Dies liegt nicht daran, dass die Protokollierung häufiger ein großes Problem darstellt, sondern daran, dass eine übermäßige Protokollierung bedeutet, dass das Protokoll nur mehr Speicherplatz beansprucht, ohne mehr Informationen zu enthalten. Sobald Sie die Ausnahme protokolliert haben, können Sie dem Benutzer / Client mit gutem Gewissen eine Précis melden (sofern Sie auch den Zeitpunkt der Generierung - oder eine andere Korrelationskennung - in diesen Bericht aufnehmen, damit die Kurzversion abgeglichen werden kann ggf. mit dem Detail).
Die beste Option ist natürlich, die Ausnahme vollständig zu behandeln und die Fehlersituation in ihrer Gesamtheit zu behandeln. Wenn Sie dies können, tun Sie es auf jeden Fall! Dies kann sogar bedeuten, dass Sie die Ausnahme nicht protokollieren müssen.
Eine Möglichkeit, eine Ausnahme zu behandeln, besteht darin, eine andere Ausnahme auszulösen, die eine übergeordnete Beschreibung des Problems enthält (z. B. " failed to initialize" anstelle von " index out of bounds"). Dies ist ein gutes Muster, solange Sie nicht die Informationen über die Ursache der Ausnahme verlieren. Verwenden Sie die detaillierte Ausnahme, um die Ausnahme causeder übergeordneten Ausnahme zu initialisieren oder das Detail zu protokollieren (wie oben erläutert). Die Protokollierung ist am besten geeignet, wenn Sie eine prozessübergreifende Grenze überschreiten möchten, z. B. einen IPC-Aufruf, da nicht garantiert werden kann, dass die Ausnahmeklasse auf niedriger Ebene überhaupt am anderen Ende der Verbindung vorhanden ist. Das Festhalten als angehängte Ursache ist am besten geeignet, wenn eine innere Grenze überschritten wird.
Ein weiteres Muster, das Sie sehen, ist Catch-and-Release:
try {
// ...
} catch (FooException e) {
throw e;
}
Dies ist ein Anti-Pattern, es sei denn, Sie haben Typeinschränkungen aus anderen catchKlauseln, die bedeuten, dass Sie die Ausnahme nicht einfach von alleine übergehen lassen können. Dann ist es nur eine hässliche Funktion von Java.
Es gibt keinen wirklichen Unterschied zwischen aktivierten und nicht aktivierten Ausnahmen außer der Tatsache, dass Sie aktivierte Ausnahmen deklarieren müssen , die Methodengrenzen überschreiten. Es ist immer noch eine gute Idee, ungeprüfte Ausnahmen (mit dem @throwsJavadoc-Kommentar) zu dokumentieren, wenn Sie wissen, dass sie absichtlich von Ihrem Code ausgelöst werden. Werfen Sie nicht absichtlich java.lang.Erroroder seine Unterklassen (es sei denn, Sie schreiben eine JVM-Implementierung).
Meinung: Ein unerwarteter Fehlerfall stellt immer einen Fehler in Ihrem Code dar. Überprüfte Ausnahmen sind eine Möglichkeit, diese Bedrohung zu verwalten. Wenn Entwickler absichtlich ungeprüfte Ausnahmen verwenden, um die Probleme bei der Behandlung von Fehlerfällen zu vermeiden, bauen Sie eine Menge technischer Schulden auf, die Sie einige Zeit bereinigen müssen Wenn Sie robusten Code wünschen. Eine schlampige Fehlerbehandlung ist unprofessionell (und die Fehlerbehandlung ist ein guter Weg, um festzustellen, wie gut ein Programmierer wirklich ist).