Benötigen Sie maßgebliche Quelle für, warum Sie java.lang.Exception nicht werfen oder fangen sollten

Question

Ich habe ein coding Standards Treffen in etwas in einer Stunde und ich brauche eine schnelle Antwort zu diesem.

Allgemeinwissen unter erfahrenen Java-Programmierern ist, dass Sie java.lang.Exception nicht werfen oder fangen (mit seltenen Ausnahmen - kein Wortspiel beabsichtigt). Der Grund, warum Sie dies nicht tun, ist, dass die Aussage

catch (java.lang.Exception ex) {...} 

wird auch nicht markiert Ausnahmen fangen, und in den meisten Fällen ist dies nicht das, was beabsichtigt ist.

Wir haben bereits eine Menge Legacy-Code von bestehenden Teammitgliedern geschrieben, in dem sie eine Unterklasse von java.lang.Exception abfangen, einen Fehler protokollieren und die Unterklasse als java.lang.Exception erneut auslösen.

Ich brauche sie davon zu überzeugen, dass

1. Sie brauchen, so zu stoppen Code zu schreiben.
2. bestehende Code, der dieses anti-Muster verwendet muss

Nummer 2 bedeutet einen fairen Betrag von Refactoring fixiert werden.

Es wird das Argument auf der Sitzung verkürzen, wenn ich einen Artikel oder einen Blog-Eintrag von einem der Java-Community-Schwergewichte zeigen kann, die diesen Punkt (d. H. Joshua Bloch, James Gosling) macht. Mein Google-Fu hat bisher noch nichts gefunden.

Kennt jemand einen Artikel oder Blog von einem respektierten Java-Guru, der besagt, dass Sie java.lang.Exception nicht werfen oder fangen sollten?

Schnelle Antworten werden sehr geschätzt.

Dean

Answer 1

Ich denke, der Punkt, dass, wenn Sie nicht wissen, wie eine spezifische Ausnahme zu behandeln, dann sollten Sie es nicht fangen. Es sollte sich auf ein höheres Niveau ausbreiten in der Hoffnung, dass es wissen könnte, was damit zu tun ist. Wenn Ausnahmen zu früh eingefangen werden, führt dies dazu, dass Ausnahmen stillschweigend verschluckt werden und es unmöglich wird, mit ihnen außer der Protokollierung etwas Nützliches zu tun.

Stellen Sie sich vor, was passieren würde, wenn der Konstruktor FileInputStream eine Ausnahme intern protokolliert, wenn Sie versucht haben, eine Datei zu öffnen, die nicht existiert, aber diesen Fehler nicht Ihrem Code angezeigt hat. Es ist in Ordnung, dass der Fehler protokolliert wird, aber Ihr Code möchte diese Ausnahme abfangen und etwas Nützliches damit machen (zB den Benutzer nach einem neuen Dateinamen fragen). Wenn sie zu catch (Exception) wären, könnten Sie das nicht tun.

Answer 2

Wenn Sie eine Kopie von Josh Blochs Effektivem Java zur Hand haben, weiß ich, dass er die Ausnahmebehandlung in einem guten Detail behandelt. Ich habe momentan keinen Zugriff darauf, also kann ich es nicht zusammenfassen oder dir Seitenverweise geben, aber ich bin mir ziemlich sicher, dass er gute Argumente dafür hat, java.lang.Exception nicht zu fangen.

Answer 3

Hier ist Bruce Eckel's viewpoint on checked exceptions in general, die in den meisten Fällen eine schlechte Idee ist. Vielleicht wird das etwas haben, das du benutzen kannst.

Answer 4

Hier gibt es keine Gemeinsamkeiten.Sie werden zwei Gruppen finden:

1. Diejenigen, die überprüft Ausnahmen hassen sie in einem RuntimeException irgendeiner Art fangen und wickeln.

2. Diejenigen, die RuntimeException

Die erste Gruppe Hass hasst ihren Code mit try...catch zu durchlöchern, zumal in den meisten Fällen können Sie die Ausnahme nicht behandeln, wenn Sie es zuerst sehen. Think IOException: Es könnte für jedes Byte, das Sie lesen, geworfen werden. Was ist der Low-Level-Code dafür? Es muss neu gestartet werden, damit jemand, der höher ist, dem Fehler einen nützlichen Kontext hinzufügen kann (wie die Datei, die Sie gerade gelesen haben).

Die andere Gruppe möchte sehen, was schief gehen könnte. RuntimeException verbirgt dies effektiv.

Es gibt eine einfache Lösung, BTW: Machen Sie Ausnahme RuntimException zu verlängern. Wahnsinnig? Nicht wirklich. Wenn Sie das mit JDK 7 tun, erhalten Sie zwei Kompilierungsfehler.

Der nächste Schritt wäre, alle Java-Compiler alle Laufzeitausnahmen aufzulisten und sie im Eintrag throws in der Klassendatei aufzulisten. Du musst sie immer noch nicht fangen, aber jetzt wirst du wissen, welche passieren könnten.

Zuletzt erweitern Sie die IDEs, um dies anzuzeigen. Und presto, beide Gruppen könnten glücklich sein. Leider wird dies nicht passieren.

Answer 5

Hier ist etwas: Java Tip 134: When catching exceptions, don't cast your net too wide (Javaworld)

Effective Java (Second Edition) von Joshua Bloch könnte etwas dazu in Kapitel 9 (Ausnahmen), obwohl ich nicht schnell etwas finden konnte nur Exception zu kontrollieren.

Hier ist a Q&A from JavaWorld über die Frage (zeigt auch auf Java Tipp 134) - es erklärt auch, warum Sie manchmal die Regel brechen müssen Exception oder sogar Throwable nicht zu fangen.

Answer 6

Siehe this article von Brian Goetz (der Concurrency-Assistenten), der auch unter Angabe Josh Bloch in Effective Java

Answer 7

wo sie fangen eine Unterklasse von java.lang.Exception, melden Sie einen Fehler seine eigene Einsicht hat, und erneut die Unterklasse als java.lang.Exception. Ich muss sie davon überzeugen, dass sie aufhören müssen, Code wie diesen zu schreiben.

Ich stimme zu, sie sollten eine andere Taktik verwenden, aber aus verschiedenen Gründen. Es ist nicht sehr sinnvoll, eine Ausnahme zu erfassen, nur um sie zu protokollieren und erneut auszulösen.

Eine Alternative ist: fangen Sie nicht die Ausnahme und lassen Sie etwas höheren Code (wie ein Java-EE-Filter oder versuchen/fangen in Ihrer main() -Methode) fangen und protokollieren alle nicht abgefangenen Ausnahmen. Dann stellen Sie sicher, dass jede Ausnahme nur einmal protokolliert wird, und Sie wissen, dass alle nicht abgefangenen Ausnahmen protokolliert werden.

Wenn Sie der Ausnahme zusätzliche Informationen hinzufügen müssen, fangen Sie sie ab, ändern Sie die Nachricht und wiederholen Sie sie.Normalerweise verwende ich eine Runtime dafür:

} catch (Exception originalException) { 
    throw new RuntimeException("user name was " + userName, originalException); 
} 

Answer 8

es ist ein langer Artikel aber this bietet Ihnen:

1. Verwendung Ausnahmen überprüft, wenn der Kunde dieser Fehler erwartet regelmäßig auftreten und damit umgehen müssen (ex: user DB-Server ging)

In der Theorie # 1 (exp: -entered Daten nicht Validierung)

Verwendung ungeprüfte Ausnahmen für unerwartete Bedingungen (ex passieren Fehler() sollten ihren eigenen Ausnahmetyp haben, und der einzige Ort, der eine # 2 (eine RuntimeException) abfangen sollte, ist eine Art von Top-Level-Handler, der die Ausnahme abfängt, sie protokolliert und dem Benutzer eine Fehlermeldung anzeigt Hier sollten Sie wahrscheinlich Throwable abfangen, um sicherzustellen, dass alle nicht abgefangenen Ausnahmen behandelt werden.

Nach diesen Richtlinien sollten Sie keine Exception abfangen, da sie keines der obigen Kriterien erfüllt (was bedeutet, dass es sich nicht um eine RuntimeException handelt und keine spezialisierte Exception-Sublcase zur Angabe eines erwarteten Fehlers ist).

Answer 9

Hier ist eine sehr insightful article

Zusammenfassung:

1. Verwenden geprüfte Ausnahmen für seltene, aber gültig Eventualitäten, die den Zweck des Codes beziehen. Client-Code sollte wissen, wie man damit umgeht.

2. Verwenden Sie ungeprüfte Ausnahmen für Fehler, die nicht passieren sollten, aber tun. (Server down, Klassenpfad falsch konfiguriert, SQL-Syntaxfehler usw.) Der IT-Typ, der den Server verwaltet, oder der Entwickler, der einfach bad preparedStatement() übergeben hat, sollte wissen, wie er diese Probleme beheben kann. Fehler sollten sich bis zur Protokollierungsschicht ausbreiten, damit die Informationen nicht verloren gehen.