try. catch Verwendung

[Guest]

Mal angenommen ich was das der Code "irgendwas" auf jedenfalls zwei verschiedene Fehler werfen kann. Ich bin mir allerdings nicht ganz sicher ob noch ein dritter Fehler geworfen werden kann. Wäre es im diesem Fall sinnvoll den dritten catch-Block für sonstige Fehler zu nutzen oder lasse ich diesen besser weg?

 try 
{
            // irgendwas
}  
catch ( AException e ) 
{
            // FehlerA
} 
catch ( BException e ) 
{
            // FehlerB
} 
catch ( Exception e ) 
{
            // sonstiger Fehler
 }

 

[maki]

Fange die Exceptions die du erwartest.

Fange nie Objekte der "Exception" Klasse selbst.

 

[Leroy42]

Fange nie Objekte der "Exception" Klasse selbst.

Nur wenn du extrem faul bist

(wie ich manchmal... 🙁 )

 

[ARadauer]

Fange nie Objekte der "Exception" Klasse selbst.

ich muss mich leider auch als java.lang.Exception Fänger outen. 😳

Ich bin mir allerdings nicht ganz sicher ob noch ein dritter Fehler geworfen werden kann.

in wie fern nicht ganz sicher? wenn die aufgerufene methode diese exception werfen kann, dann kann sie geworfen werden. das ist doch ziehmlihc sicher oder?

 

[Guest]

Was bringt es mir eigentlich Fehler abzufangen. Mal angenommen ich würde sie nicht abfangen. Dann würde der Fehler bis zur höchsten Instanz weitergeleitet. Diese würde das Programm dann abbrechen und den Fehler auf dem Bildschirm ausgeben. Folglich wüßte ich um welchen Fehler es sich handelt und könnte diesen entsprechend beheben.

 

[Guest]

Am Code ändern muß ich ja sowieso etwas wenn ein Fehler geworfen wird... also auch wenn ich ihn expliziet abfange.

 

[maki]

Was bringt es mir eigentlich Fehler abzufangen. Mal angenommen ich würde sie nicht abfangen. Dann würde der Fehler bis zur höchsten Instanz weitergeleitet. Diese würde das Programm dann abbrechen und den Fehler auf dem Bildschirm ausgeben. Folglich wüßte ich um welchen Fehler es sich handelt und könnte diesen entsprechend beheben.

Dieses vorgehen ist bei Exceptions angebracht, die ihre Ursache in Programmfehlern haben (zB IndexOutOfBoundsException etc.), mit so einer Exception kann man nicht mehr viel anfangen.

Mit sog. "checked" Exceptions (keine Unterklasse der RuntimeException) ist der Fall anders, zB wenn man auf eine Datenbank oder auf das Dateisystem zugreift.
In so einem Fall muss man immer damit rechnen, dass es zu Fehlern kommen kann, schliesslich sind diese externen Ressourcen nicht steuerbar, in so einem Falle fägt man die Exception und bringt dem User eine sinnolle Meldung und das Programm läuft normal und kontrolliert weiter.

Eines der Probleme wenn man Objekte der "Exception" Klasse selbst fängt: Man kann zwischen checked und unchecked Exception nicht unterscheiden, es werden einfach alle gefangen.

 

[Guest]

1.)
Mal angenommen ich will auf eine Datei zugreifen. Wenn das nicht klappt gibt es ja eine IOException. Da deswegen trotzdem noch die Grundfunktionalität der Anwendung funktioniert ist es sinnvoll solch eine Fehler abzufangen.

IOException = "checked" Exception (keine Unterklasse der RuntimeException)

2.)
Wenn aber z.B. eine OutOfBoundsException wegen einem Arrayüberlauf geworfen wird, so ist es nicht sinnvoll diesen abzufangen da damit im Gegensatz zum ersten Beispiel die Grundfunktionalität der Anwendung nichtmehr gewährleistet ist.

OutOfBoundsException = Exception mit der Oberklasse RuntimeException

3.)
Es ist also sinnvoll alle Exceptions die als Oberklasse NICHT die Klasse RuntimeException besitzen abzufangen. Folglich ist das Abfangen von Exceptions grundsätzlich quatsch, da sie eine Objerklasse von RuntimeException sind und somit nicht klar ist welchen Typ von Fehler man abfängt.

Sind die Erklärungen soweit korrekt? Ich bin für Berichtigunen und Ergänzungen offen...

 

[maki]

1.)
Mal angenommen ich will auf eine Datei zugreifen. Wenn das nicht klappt gibt es ja eine IOException. Da deswegen trotzdem noch die Grundfunktionalität der Anwendung funktioniert ist es sinnvoll solch eine Fehler abzufangen.

IOException = "checked" Exception (keine Unterklasse der RuntimeException)

Ja.

2.)
Wenn aber z.B. eine OutOfBoundsException wegen einem Arrayüberlauf geworfen wird, so ist es nicht sinnvoll diesen abzufangen da damit im Gegensatz zum ersten Beispiel die Grundfunktionalität der Anwendung nichtmehr gewährleistet ist.

OutOfBoundsException = Exception mit der Oberklasse RuntimeException

Sehe ich genauso.

3.)
Es ist also sinnvoll alle Exceptions die als Oberklasse NICHT die Klasse RuntimeException besitzen abzufangen. Folglich ist das Abfangen von Exceptions grundsätzlich quatsch, da sie eine Objerklasse von RuntimeException sind und somit nicht klar ist welchen Typ von Fehler man abfängt.

Sind die Erklärungen soweit korrekt? Ich bin für Berichtigunen und Ergänzungen offen...

Richtig.

Es gibt natürlich immer Ausnahmen etc., kommt auf den konkreten Fall an.

Man muss sich schon überlegen, was man mit der gefangenen Exception anfangen kann und will.

Nebenbei bemerkt, Errors (implmentieren Throwable) kann man nicht fangen, weil man damit garaniert nix sinnvolles anfangen kann, oder was sollte man zB mit einem OutOfMemoryError anstellen?

Auch gibt es ein Prinzip das sich ExceptionTranslation nennt.
Eine SQL Exception ist für den User meist sinnfrei, besser wäre zB eine "ServiceException" (eigene checked Exception Klasse) die ihm erklärt das es einen Fehler in der DB gibt, d.h. das zB meine EJB nur noch ServiceExceptions werfen, die DAO Schicht sollte nur DAOExceptions werfen etc. vereinfacht die Handhabung um einiges.

Links zu diesem Thema:

http://www.javaworld.com/javaworld/jw-08-2000/jw-0818-exceptions.html
http://www.javaworld.com/javaworld/javaqa/2003-02/02-qa-0228-evilthrow.html
http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html
http://java.sun.com/docs/books/tutorial/essential/exceptions/
http://java.sun.com/docs/books/tutorial/essential/exceptions/handling.html
http://jenkov.com/training/java_exception_handling/checked_vs_unchecked_exceptions.tmpl

 

[Guest]

😀 Super dann hab ich den Kram auch endllich verstanden...

 

[DP]

oder du erwartest eine zahl vom user und bekommst einen buchstaben. mit einer numberformatexception kannste dem user direkt mitteilen dass er gefälligst nur zahlen einzugeben hat...

 

[maki]

oder du erwartest eine zahl vom user und bekommst einen buchstaben. mit einer numberformatexception kannste dem user direkt mitteilen dass er gefälligst nur zahlen einzugeben hat...

Ja, das wäre einer der Ausnahmen, in denen man auch RuntimeExceptions fängt, weil es eine sinnvolle Möglichekit gibt damit umzugehen und man erwarten kann, dass der User mal was doofes probiert.