Frage zu Exceptionhandling

[Maik.Neumann]

Guten Tag,

ich habe mal eine Frage zu dem Exceptionhandling in Java. Nun ist es ja so, dass CheckedExceptions (wie z.B. eine FileNotFoundException) explizit von mir als Programmierer behandelt werden müssen und die UncheckedException (wie z.B. eine ArrayIndexOutOfBoundsException) kann von mir behandelt werden, muss sie aber nicht.

Nun könnte ich ja die Exception direkt in der Methode behandeln, in der sie auftritt, oder eben mit throws an den Aufrufer der entsprechenden Methode weitergeben, wenn ich Sie nicht behandeln möchte.

Unter dem Aspekt der Wiederverwendung einer Klasse inkl. derer Methoden stellt sich für mich die folgende Frage:

Wann macht es Sinn etwas direkt in der Methode zu behandeln und wann macht es Sinn, eine Exception weiterzuwerfen? Und wenn ich Sie weiterwerfe, wo solte sie dann behandelt werden?

Ich wei, dass das auch sehr vom Gesamtkontext meiner Anwendung abhängt, aber gibt es da eine Art Faustregel?

Danke und Gruß

 

[turtle]

wo solte sie dann behandelt werden?

It depends

Das ist (natürlich) abhängig von der Exception und dem Kontext.

Nehmen wir dein Beispiel FileNotFoundException.

Wie kann da eine Behandlung aussehen?

Dem User wird ein JFileChooser angeboten und geprüft, ob Datei vorhanden und lesbar ist.

Kommt beim Zugriff die Exception kann wieder der JFileChooser aufgehen und der User kann erneut eine Datei auswählen. Also KANN hier eine sinnvolle Bahndlung gemacht werden.

Beim Starten der Applikation liest das Programm Einstellungen aus einer Konfigurationsdatei. Wie kann hier eine Behandlung aussehen? Wenn das Programm nicht ohne Einstellungen arbeiten kann, ist KEINE sinnvolle Behandlung möglich und die Exception sollte weiter geworfen werden.

Im Bereich der Datenbank gibt es beispielsweise viele unterschiedliche SQLExceptions, unter anderem wenn eine Verbindung zur Datenbank hergestellt wird. In den seltensten Fällen kann hier eine sinnvolle Behandlung gemacht werden...

gibt es da eine Art Faustregel?

Nein,lies obige Begründung

 

[Maik.Neumann]

Danke für deinen Beitrag !

Wenn das Programm nicht ohne Einstellungen arbeiten kann, ist KEINE sinnvolle Behandlung möglich und die Exception sollte weiter geworfen werden.

Wohin würdest Du sie denn in diesem Fall werfen? Mir ist das Wurfziel und eine mögliche Abhandlung dieser Exception nicht klar.

In den seltensten Fällen kann hier eine sinnvolle Behandlung gemacht werden...

Auch hier ist mir nicht ganz klar, wohin die Exception geworfen werden sollte und vor allem, wie sie einmal behandelt werden soll, sobald sie geworfen wurde.

 

[Natac]

Die Frage ist: Wer KANN die Exception sinnvoll behandeln?

Wenn du sinnvoll auf eine Exception reagieren kannst, dann fange sie und reagiere darauf.
Wenn du nicht sinnvoll auf eine Exception reagieren kannst, dann wirf sie weiter.

Wer über dir in der Kette steht, weißt du als aufgerufenes Stück Code ja meistens nicht. Und es ist auch prinzipiell gut darüber keine Annahmen zu machen.

In meinen Applikationen setzte ich möglichst früh ein DefaultUncaughtExceptionHandler, der aufgerufen wird, wenn eine Exception bis zur VM durchgeflogen ist. Meistens gibt der dann eine Fehlermeldung aus und schreibt die Exception in ein logfile. Viel mehr kann man an dieser Stelle dann auch nicht mehr machen. Zumindest sieht der Nutzer so, dass es einen Fehler gab und ich hab eine Datei, in der ich mir das anschauen kann.

 

[turtle]

Wohin würdest Du sie denn in diesem Fall werfen? Mir ist das Wurfziel und eine mögliche Abhandlung dieser Exception nicht klar.

Das hat Natac schon richtig beschrieben. Bleiben wir beim Beispiel

    public void readEinstellungen(File file) throws FileNotFoundException {
	BufferedReader bufferedReader = new BufferedReader(new FileReader(file));
	// ...
    }

Du siehst, es gibt keine sinnvolle Behandlung also werfen wir die Exception weiter. Das bedeutet, das sich "jemand" darum kümmern sollte. Man sagt auch, die Exception wird im Call-Stack hochgereicht, bis einer die Exception behandelt. Wie ebenfalls Natac richtig sagte, kann man einen Handler registrieren, der quasi die letzte Ausfahrt der JVM darstellt. Ansonsten würde die JVM das Programm abbrechen.

 

[Maik.Neumann]

Danke für eure bisherigen Beiträge !

Wer über dir in der Kette steht, weißt du als aufgerufenes Stück Code ja meistens nicht. Und es ist auch prinzipiell gut darüber keine Annahmen zu machen.

Das bedeutet im Umkehrschluss aber auch, dass in ""höcherliegenden" Methoden zusätzliche throws Deklarationen in die Methodenköpfe eingefügtw erden müssen (u.U. auch sehr viele und sehr viele speziellierte Exceptions).

Führt das aber wieder nicht zu stark aufgeblähten Methodenköpfen und ggf. komplexeren Code? Was wäre hier eine mögliche Abhilfe? Einfach nur throws Exception schreiben?

Danke und Gruß

 

[turtle]

Was wäre hier eine mögliche Abhilfe?

Das wird sehr kontrovers diskutiert im Java-Lager

Die eine Fraktion befürwortet den Verzicht auf checked Exceptions und mehr Runtime Exceptions.
Die andere Fraktion findet den Status-Quo ausreichend.

Ich sehe das etwas differenzierter und führe als Beispiel SQLExceptions an.

Es gibt Code, der auf Datenbanken zugreift und häufig benutzt man dazu ein ORM-Framework wie Hibernate. Ein Problem mit checked Exceptions ist, das nun unterliegend SQLExceptions auftreten können, diese nach oben gereicht werden und dort in der Business-Logik der Applikation auftreten. Dieses betrachten viele als Leck (leak), weil Implementierungsdetails in Schichten sichtbar sind, die das eigentlich nichts angeht. Daher wurde in Hibernate die HibernateException eingefügt, eine Runtime-Exception, die derartige Probleme verhindert.

Daher finde ich, das Exceptions SEHR genau entworfen gehören und man einen Kompromiss zwischen klarem Code, Aussagefähigkeit und Wartbarkeit finden muss.