Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
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?
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?
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.
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.
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...
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...
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.
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...
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.
)
