Wofür eignen sich geprüfte Ausnahmen in Java? [geschlossen]

Javas geprüfte Ausnahmen haben im Laufe der Jahre schlechte Presse bekommen. Ein aussagekräftiges Zeichen ist, dass es buchstäblich die einzige Sprache auf der Welt ist, in der sie vorkommen (nicht einmal andere JVM-Sprachen wie Groovy und Scala). Prominente Java-Bibliotheken wie Spring und Hibernate verwenden sie ebenfalls nicht.

Ich persönlich habe eine Verwendung für sie gefunden ( in der Geschäftslogik zwischen den Ebenen), aber ansonsten bin ich ziemlich gegen Ausnahmen.

Gibt es andere Verwendungen, die ich nicht kenne?

Zunächst müssen Sie, wie bei jedem anderen Programmierparadigma, alles richtig machen, damit es funktioniert.

Für mich ist der Vorteil von geprüften Ausnahmen , dass die Autoren der Java - Laufzeitbibliothek haben für mich schon entschieden , welche gemeinsame Probleme könnte ich vernünftigerweise in der Lage sein zu erwarten, bei der Handhabung Aufruf Punkt (im Gegensatz zu einem Top-Level - catch-Print- gegen Block) und überlegen Sie so früh wie möglich, wie mit diesen Problemen umgegangen werden soll.

Ich mag geprüfte Ausnahmen, weil sie meinen Code robuster machen, indem sie mich dazu zwingen, so früh wie möglich über eine Fehlerbehebung nachzudenken.

Um genauer zu sein, macht dies meinen Code robuster, da ich gezwungen bin, sehr früh im Prozess seltsame Eckfälle zu berücksichtigen, anstatt zu sagen, dass "Hoppla, mein Code nicht funktioniert, wenn die Datei noch nicht existiert" ein Fehler in der Produktion, den Sie dann Ihren Code überarbeiten müssen, um zu behandeln. Das Hinzufügen von Fehlerbehandlung zu vorhandenem Code kann eine nicht triviale und daher teure Aufgabe sein, wenn die Wartung erreicht wird, anstatt dies von Anfang an zu tun.

Es kann sein, dass die fehlende Datei eine fatale Sache ist und das Programm in Flammen zum Absturz bringen sollte, aber dann treffen Sie diese Entscheidung mit

} catch (FileNotFoundException e) {
  throw new RuntimeException("Important file not present", e);
}

Dies zeigt auch einen sehr wichtigen Nebeneffekt. Wenn Sie eine Ausnahme umbrechen, können Sie eine Erklärung hinzufügen, die in den Stack-Trace aufgenommen wird ! Dies ist äußerst leistungsfähig, da Sie Informationen hinzufügen können, z. B. den Namen der fehlenden Datei, die an diese Methode übergebenen Parameter oder andere Diagnoseinformationen, und diese Informationen direkt im Stack-Trace vorhanden sind, der häufig der einzige ist, den Sie verwenden erhalten, wenn ein Programm abgestürzt ist.

Die Leute mögen sagen, "wir können dies einfach im Debugger ausführen, um es zu reproduzieren", aber ich habe festgestellt, dass Produktionsfehler sehr häufig nicht später reproduziert werden können , und wir können keine Debugger in der Produktion ausführen, außer in sehr bösen Fällen, in denen im Wesentlichen Ihre Aufgabe auf dem Spiel steht.

Je mehr Informationen sich in Ihrem Stack-Trace befinden, desto besser. Überprüfte Ausnahmen helfen mir dabei, diese Informationen frühzeitig zu erhalten.

EDIT: Dies gilt auch für Bibliotheksdesigner. Eine Bibliothek, die ich täglich benutze, enthält viele, viele überprüfte Ausnahmen, die viel besser entworfen worden sein könnten, was die Verwendung weniger mühsam macht.

Sie haben zwei gute Antworten, die erklären, was geprüfte Ausnahmen in der Praxis geworden sind. (+1 an beide.) Es lohnt sich aber auch zu prüfen, wofür sie eigentlich gedacht sind, denn die Absicht lohnt sich tatsächlich.

Aktivierte Ausnahmen sollen die Sicherheit der Sprache erhöhen. Betrachten Sie eine einfache Methode wie die ganzzahlige Multiplikation. Sie könnten denken, dass der Ergebnistyp dieser Methode eine Ganzzahl ist, aber genau genommen ist das Ergebnis entweder eine Ganzzahl- oder eine Überlaufausnahme. Das Betrachten des ganzzahligen Ergebnisses als Rückgabetyp der Methode drückt nicht den gesamten Funktionsumfang aus.

In diesem Licht ist es nicht unbedingt richtig zu sagen, dass geprüfte Ausnahmen nicht in andere Sprachen gelangt sind. Sie haben einfach nicht die Form angenommen, die Java verwendet hat. In Haskell-Anwendungen werden häufig algebraische Datentypen verwendet, um zwischen erfolgreicher und nicht erfolgreicher Ausführung der Funktion zu unterscheiden. Obwohl dies an sich keine Ausnahme ist, entspricht die Absicht weitgehend einer überprüften Ausnahme. Es ist eine API, die entwickelt wurde, um den API-Konsumenten zu zwingen, sowohl den erfolgreichen als auch den erfolglosen Fall zu behandeln, z.

data Foo a =
     Success a
   | DidNotWorkBecauseOfA
   | DidNotWorkBecauseOfB

Dies teilt dem Programmierer mit, dass die Funktion neben dem Erfolg zwei weitere mögliche Ergebnisse hat.

IMO, geprüfte Ausnahmen sind eine fehlerhafte Umsetzung von dem, was könnte ein recht ordentliches Idee gewesen (unter völlig anderen Umständen - aber wirklich ist nicht einmal eine gute Idee , unter der aktuellen Situation).

Die gute Idee ist, dass der Compiler überprüfen muss, ob alle Ausnahmen, die ein Programm auslösen kann, abgefangen werden. Die fehlerhafte Implementierung besteht darin, dass Java Sie dazu zwingt, die Ausnahme direkt in einer beliebigen Klasse zu behandeln, die alles aufruft, was als Auslöser einer aktivierten Ausnahme deklariert wurde. Eine der grundlegendsten Ideen (und Vorteile) der Ausnahmebehandlung besteht darin, dass im Fehlerfall zwischengeschaltete Codeschichten, die nichts mit einem bestimmten Fehler zu tun haben, dessen Existenz vollständig ignorieren können. Überprüfte Ausnahmen (wie sie in Java implementiert sind) lassen dies nicht zu, wodurch zunächst ein wesentlicher (der primäre?) Vorteil der Ausnahmebehandlung zunichte gemacht wird.

Theoretisch hätten sie geprüfte Ausnahmen nützlich machen können, indem sie sie nur auf programmweiter Basis erzwangen - dh während sie das Programm "bauen", bauen sie einen Baum aller Steuerpfade im Programm. Verschiedene Knoten im Baum würden mit 1) Ausnahmen, die sie erzeugen können, und 2) Ausnahmen, die sie abfangen können, mit Anmerkungen versehen. Um sicherzustellen, dass das Programm korrekt ist, müssen Sie den Baum durchgehen und sicherstellen, dass jede Ausnahme, die auf einer beliebigen Ebene im Baum ausgelöst wurde, auf einer höheren Ebene im Baum abgefangen wurde.

Der Grund, warum sie das nicht gemacht haben (ich denke jedenfalls), ist, dass es entsetzlich schwierig wäre, dies zu tun - in der Tat bezweifle ich, dass jemand ein Build-System geschrieben hat, das das für alles andere als extrem einfache Dinge (an der Grenze zu "Spielzeug") kann ") Sprachen / Systeme. Für Java ist das Laden dynamischer Klassen noch schwieriger als in vielen anderen Fällen. Schlimmer noch, (im Gegensatz zu C) ist Java nicht (zumindest normalerweise) statisch kompiliert / mit einer ausführbaren Datei verknüpft. Das heißt, nichts im System hat wirklich das globale Bewusstsein, diese Art der Durchsetzung auch nur zu versuchen , bis der Endbenutzer tatsächlich beginnt, das Programm zu laden, um es auszuführen.

Die Durchsetzung zu diesem Zeitpunkt ist aus mehreren Gründen unpraktisch. Zuallererst würde es bestenfalls die Startzeiten verlängern, die bereits zu den größten und häufigsten Beschwerden über Java zählen. Zweitens, um viel Gutes zu tun, müssen Sie das Problem wirklich früh genug erkennen, damit ein Programmierer es beheben kann. Wenn der Benutzer das Programm geladen wird, ist es zu spät viel Gutes zu tun - Ihre einzige Wahl an diesem Punkt sind das Problem, oder Abfall zu laden / starten Sie das Programm überhaupt, auf gut Glück zu ignorieren , dass es könnte eine Ausnahme sein das wurde nicht erwischt.

So wie sie sind, sind geprüfte Ausnahmen schlimmer als nutzlos, aber alternative Entwürfe für geprüfte Ausnahmen sind noch schlimmer. Die Grundidee für geprüfte Ausnahmen scheint zwar gut zu sein, ist aber nicht sehr gut und passt besonders schlecht zu Java. Für etwas wie C ++, das normalerweise zu einer vollständigen ausführbaren Datei kompiliert / verknüpft wird, die nichts mit dem Laden von Reflection / Dynamic Class zu tun hat, hätten Sie eine etwas größere Chance (obwohl Sie diese, ganz offen gesagt, auch dann korrekt erzwingen, ohne die gleiche Art von Chaos Ursache in Java wäre derzeit wohl noch jenseits des aktuellen Standes der Technik).

Sie sind wirklich gut für nervige Programmierer und fördern das Verschlucken von Ausnahmen. Die Hälfte der Ausnahmen besteht darin, dass Sie eine vernünftige Standardmethode zum Behandeln von Fehlern verwenden und nicht daran denken müssen, Fehlerzustände, die Sie nicht behandeln können, explizit zu verbreiten. (Der vernünftige Standard ist, dass Sie, wenn Sie den Fehler an keiner Stelle in Ihrem Code behandeln, effektiv behauptet haben, dass er nicht auftreten kann, und einen vernünftigen Exit und einen Stack-Trace erhalten, wenn Sie sich irren.) Überprüfte Ausnahmen besiegen Dies. Sie haben das Gefühl, Fehler in C explizit verbreiten zu müssen.

Ich denke, es ist fair zu sagen, dass überprüfte Ausnahmen ein bisschen ein fehlgeschlagenes Experiment waren. Was sie falsch gemacht haben, ist, dass sie die Schichtung gebrochen haben:

• Modul A könnte auf Modul B aufbauen, wo
• Modul B kann auf Modul C aufbauen.
• Modul C kann einen Fehler identifizieren und
• Modul A weiß möglicherweise, wie mit dem Fehler umgegangen wird.

Die schöne Trennung der Betroffenen ist gebrochen, weil nun die Kenntnis von Fehlern, die sich auf A und C hätten beschränken können, über B verstreut werden muss.

Es gibt eine nette Diskussion über geprüfte Ausnahmen auf Wikipedia.

Und Bruce Eckel hat auch einen schönen Artikel darüber. Hier ist ein Zitat:

[D] Je mehr zufällige Regeln Sie auf den Programmierer stapeln, desto langsamer kann der Programmierer produzieren. Regeln, die nichts mit der Lösung des vorliegenden Problems zu tun haben. Und dies scheint kein linearer Faktor zu sein, sondern ein exponentieller

Ich glaube für den Fall von C ++, wenn alle Methoden die throwsSpezifikationsklausel haben, dann können Sie einige nette Optimierungen haben. Ich glaube jedoch nicht, dass Java diese Vorteile haben könnte, da RuntimeExceptionses nicht aktiviert ist. Ein modernes JIT sollte in der Lage sein, den Code auf jeden Fall zu optimieren.

Eine nette Funktion von AspectJ ist das Weichzeichnen von Ausnahmen: Sie können aktivierte Ausnahmen in nicht aktivierte Ausnahmen umwandeln, um das Layering zu verbessern.

Vielleicht ist es ironisch, dass Java all diese Schwierigkeiten durchgemacht hat, als es nullstattdessen hätte nachsehen können , was viel wertvoller gewesen sein könnte .

Ich liebe Ausnahmen.

Ich bin jedoch ständig amüsiert über ihren Missbrauch.

1. Verwenden Sie sie nicht für das Flow-Handling. Sie möchten keinen Code, der versucht, etwas zu tun, und eine Ausnahme als Auslöser verwendet, um stattdessen etwas anderes zu tun, da Ausnahmen Objekte sind, die erstellt werden müssen und Speicher usw. usw. verwenden, nur weil Sie nicht die Mühe hatten, etwas zu schreiben Art von if () überprüfen, bevor Sie Ihren Anruf tätigen. Das ist einfach faul und gibt der glorreichen Ausnahme einen schlechten Ruf.

2. Schluck sie nicht. Je. Unter allen Umständen. Als absolutes Minimum schreiben Sie etwas in Ihre Protokolldatei, um anzuzeigen, dass eine Ausnahme aufgetreten ist. Der Versuch, den Weg durch Code zu verfolgen, der Ausnahmen verschluckt, ist ein Albtraum. Nochmals, verfluche deine Ausnahmeschlucker, weil sie die mächtige Ausnahme in Verruf gebracht haben!

3. Behandle Ausnahmen mit aufgesetztem OO-Hut. Erstellen Sie eigene Exception-Objekte mit aussagekräftigen Hierarchien. Überlagern Sie Ihre Geschäftslogik und Ihre Ausnahmen Hand in Hand. Früher stellte ich fest, dass, wenn ich in einem neuen Bereich eines Systems anfing, die Unterklasse Exception innerhalb einer halben Stunde nach dem Codieren untergeordnet werden musste. In diesen Tagen beginne ich mit dem Schreiben der Exception-Klassen.

4. Wenn Sie 'Framework'-Codebits schreiben, stellen Sie sicher, dass alle Ihre anfänglichen Schnittstellen so geschrieben sind, dass sie gegebenenfalls Ihre eigenen neuen Ausnahmen auslösen. Stellen Sie sicher, dass Ihre Codierer über einen Beispielcode verfügen, der festlegt, was bei ihrem Code zu tun ist löst eine IOException aus, aber die Schnittstelle, an die sie schreiben, möchte eine 'ReportingApplicationException' auslösen.

Wenn Sie erst einmal gelernt haben, wie Exceptions für Sie funktionieren, werden Sie nie mehr zurückblicken.

Überprüfte Ausnahmen sind auch in ADA.

(Achtung, dieser Beitrag enthält Überzeugungen, denen Sie möglicherweise gegenüberstehen.)

Programmierer mögen sie nicht und beschweren sich oder schreiben Ausnahmeschluckcode.

Überprüfte Ausnahmen existieren, weil Dinge nicht nur nicht funktionieren können, Sie können auch eine Fehlermodus- / Effektanalyse durchführen und dies im Voraus bestimmen.

Das Lesen von Dateien kann fehlschlagen. RPC-Aufrufe können fehlschlagen. Netzwerk-E / A kann fehlschlagen. Daten können beim Parsen falsch formatiert werden.

Der "glückliche Weg" für Code ist einfach.

Ich kannte jemanden an der Universität, der großartigen "Happy Path" -Code schreiben konnte. Keiner der Randfälle hat jemals funktioniert. In diesen Tagen macht er Python für ein Open-Source-Unternehmen. Sagte Nuff.

Wenn Sie keine geprüften Ausnahmen behandeln möchten, ist das, was Sie wirklich sagen

While I'm writing this code, I don't want to consider obvious failure modes.

The User will just have to like the program crashing or doing weird things.

But that's okay with me because 

I'm so much more important than the people who will have to use the software

in the real, messy, error-prone world.

After all, I write the code once, you use it all day long.

Daher werden geprüfte Ausnahmen von Programmierern nicht gemocht, da dies mehr Arbeit bedeutet.

Natürlich hätten andere Leute diese Arbeit gerne getan.

Möglicherweise wollten sie die richtige Antwort, auch wenn der Dateiserver ausfällt oder der USB-Stick ausfällt.

Es ist ein seltsamer Glaube an die Programmierergemeinschaft, dass Sie eine Programmiersprache verwenden sollten, die Ihnen das Leben erleichtert und Ihnen Spaß macht, wenn Sie Software schreiben. Ihre Aufgabe ist es, ein Problem zu lösen, ohne dass Sie sich auf programmatische Jazzimprovisation einlassen.

Wenn Sie ein Amateur-Programmierer sind (nicht für Geld programmieren), können Sie ohne aktivierte Ausnahmen in C # oder einer anderen Sprache programmieren. Heck, schneiden Sie den mittleren Mann aus und programmieren Sie in Logo. Mit der Schildkröte können Sie hübsche Muster auf den Boden zeichnen.

Überprüfte Ausnahmen sollten die Leute dazu ermutigt haben, Fehler in der Nähe ihrer Quelle zu behandeln. Je weiter von der Quelle entfernt, desto mehr Funktionen wurden während der Ausführung beendet und desto wahrscheinlicher ist es, dass das System in einen inkonsistenten Zustand übergegangen ist. Außerdem ist es wahrscheinlicher, dass Sie versehentlich die falsche Ausnahme feststellen.

Leider haben die Leute entweder Ausnahmen ignoriert oder immer mehr Wurfspezifikationen hinzugefügt. Beide verfehlen den Sinn dessen, was geprüfte Ausnahmen anregen sollen. Sie sind wie das Transformieren von Prozedurcode, um viele Getter- und Setter-Funktionen zu verwenden, die ihn angeblich zu OO machen.

Im Wesentlichen versuchen überprüfte Ausnahmen, einen gewissen Grad an Korrektheit in Ihrem Code zu beweisen. Es ist fast die gleiche Idee wie das statische Tippen, da es zu beweisen versucht, dass bestimmte Dinge korrekt sind, bevor der Code überhaupt ausgeführt wird. Das Problem ist, dass all diese zusätzlichen Beweise Mühe kosten und sich die Mühe lohnt?