Exception Handing?

[juandeluca]

Hallo!

Wie soll Exception Handling am besten gemacht werden?

Ich bin sicher es gibt einige Theorien, wie man Exceptions am besten handeln soll und ob man sie dem User anzeigt oder sie irgendwo in eine Log-Datei schreibt.

Mich interessiert hier allerdings zuerst, wie die am meisten "zu ratendende" Methode wäre. Bisher mache ich es so, dass ich die geworfenen Exceptions soweit wie möglich den Baum hochtrage. Das bedeutet, dass ich wenn möglich auf try-catch verzichte und mich des throws oben an jeder Methode bediene, um dann in der rufenden Methode eine Lösung dazu zu finden.

Wie ist denn nun die beste Methode, um Exceptions zu managen? Gibt es in Java eine Richtlinie?

 

[Da_Tebe]

Ja gute Frage. Interessiert mich auch sehr.
Erste Richtlinie ist natürlich so zu Programmieren das keine Exceptions entstehen können.

Sobald man aber Input/Output-Streams etc. anwendet kommt man ja nicht drum rum.
Dann sollte man sich bestimmt fragen wer von der Exception wissen muss. Muss der Aufrufer der methode das verarbeiten? Oder reicht ein einfacher Logeintrag um es später nachzuvollziehen und die methode beendet sich einfach..oder versucht es nochmal... naja

Wie gesagt würde ich dazu auch gerne mal Meinungen und Vorschläge hören =)

 

[xKoRe]

Ich betrachte Exception auch gerne als zusätzlichen Rückgabewert (z.B. invalidInput). Natürlich sollte man sie dann auch direkt abfangen, allerdings hat man sofort Aufschluss darüber was passiert ist. Je früher du dich darum kümmerst, desto genauer kann der Fehler bestimmt werden.

Deswegen finde ich, kann es auch sehr sinnvoll sein eigene Exceptions einzubringen und sie absichtlich zu werfen. Von Log-Dateien halte ich nur etwas, wenn es im Zusammenspiel mit einer Userrückgabe geschieht.

Ausserdem kommt es auch immer darauf an, weswegen deine Exception ausgelöst wurde, und welcher Art sie ist.

Beispiel: Ich habe ein Eingabefeld und versuche eine Zahl auszulesen. Der User gibt Buchstaben mit ein, dadurch entsteht die Exception, die du ausschliesslich über eine Userbenachrichtigung ausgibst. Schliesslich liegt der Fehler beim Benutzer (ein völlig fehlerfreies Bedienfeld zu erstellen ist immer schwieriger).

Andererseits habe ich auch schon Ansätze gesehen, die sich darum handeln Fehler dynamisch zu lösen und nur im absoluten Scheitern den Fehler auszugeben/in eine Log zu schreiben.

Alles in allem ist meine Empfehlung: Behandle jede Exception so früh wie möglich. Nach oben tragen nur, wenn deine Exception spezifisch genug unterschieden werden können um eine sinnvolle Behandlung zu ermöglichen.

 

[tfa]

Nach oben tragen nur, wenn deine Exception spezifisch genug unterschieden werden können um eine sinnvolle Behandlung zu ermöglichen.

...oder, wenn eine Behandlung im Sinne von Behebung nicht möglich ist (was nach meiner Erfahrung auf einen Großteil der Exceptions zutrifft).
Statt an alle Methoden [c]throws[/c] dranzuschreiben, kann man eine Exception auch in eine RuntimeException kapseln. So hält man sein Interface sauber.

 

[Spacerat]

Mit RuntimeExceptions wäre ich vorsichtig, ich würde zumindest keine oder besser gesagt eher selten eigene implementieren. "Legale" Kanditaten für RTEs wären NullPointer-, IllegalArgument- und notfalls noch UnsupportedOperationException.
Am Beispiel Streams erkennt man, dass es durchaus Ausnahmefehler gibt, über die der Aufrufer informiert werden sollte. Für z.B. fehlerhafte Festplattensektoren beim Lesen einer Datei kann kein Mensch etwas. Für falsch übergebene Parameter allerdings schon.
Alles in allem bedeutet das, dass es Situationsbedingt ist (ganz wie tfa es sagt), wie man sich bei Exceptions zu verhalten hat. Hier da und dort in RTEs zu Kapseln ist deswegen auch nur manchmal eine gute Idee. Nach dem Motto: "Was soll ich mich sorgen. Mach' du dir doch Sorgen. Mir gehen die Ideen aus."

 

[tfa]

Mit RuntimeExceptions wäre ich vorsichtig, ich würde zumindest keine oder besser gesagt eher selten eigene implementieren.

Ich würde das selbe über checked Exceptions sagen. Aber egal. Diese Diskussion gab es hier ja schon öfter...