?
MachIchMal schrieb:
Es gibt auch unterschiedliche Exceptions: RuntimeExceptions (NullPointerException...) die müssen nicht gefangen bzw. mit throws angegeben werden und normale Exceptions die gefangen werden müssen.
Genau. Diese beiden Exception-Arten sollte man unterscheiden, denn sie haben auch unterschiedliche Anwendungsgebiete:
RuntimeExceptions nutzt man bei Programmierfehlern. Zum Beispiel dann, wenn jemand eine Methode falsch aufruft (Definitionsbereich wurde nicht beachtet oder irgendwas ist null oder so). Das hat Griffin ja schon gezeigt. Es geht dabei also um Fehler in externem Code, die in der eigenen Methode auffliegen. Bezüglich möglichen internen Fehlern, macht man eigentlich nur Überprüfungen von Zwischenergebnissen und so weiter mit assert. Da schmeißt man keine RuntimeException oder so. Insgesamt ist es glaube ich nicht sehr üblich, RuntimeExceptions zu fangen. Die zeigen eigentlich Bugs und keine "Ausnahmen" an. Alle Auslöser von RuntimeExceptions sollte man während der Entwicklung des Programms beseitigen.
Andere Exceptions sind normalerweise für echte Ausnahmesituationen, die nichts mit dem Programmierer zu tun haben. Also beispielsweise "Ratte zerbeißt das Netzwerkkabel" oder so. Der Programmierer sollte dafür sorgen, dass sein Programm in solchen echten Ausnahmesituationen sinnvoll weiter funktioniert und deshalb sollte man solche Ausnahmen i.d.R. fangen. Im catch-Block sollte man dann dafür sorgen, dass das Programm wieder in einen sinnvollen Zustand überführt wird und, dass der Nutzer möglich wenig Probleme durch die Ausnahme bekommt. Möglicherweise ist es sinnvoll, an dieser Stelle bestimmte Daten zu sichern oder so. Der Nutzer sollte natürlich auch über die Ausnahme informiert werden. Leere catch-Blöcke sind diesbezüglich nicht zu empfehlen. Dann merkt nämlich keiner, dass da etwas pasiert ist. Ein catch(Exception e) sollte man auch vermeiden, da man damit auch RuntimeExceptions fängt. Da macht man dann schnell mal irgendwelche Fehlinterpretationen, was die Exception betrifft.
Ansonsten gibt es noch Errors. Die sollte man nicht fangen. Ein Error heißt "Die JVM befindet sich jetzt in einem undefinierten Zustand". Das heißt, dass man in seinem Programm keine sinnvollen Annahmen mehr machen kann und deshalb sollte das Programm auch sofort beendet werden. Errors sollte man also eher vermeiden. Man könnte zum Beispiel testen, ob noch genug Speicher auf dem Heap frei ist, wenn man an eine Stelle gelangt, die diesbezüglich kritisch ist. Dadurch kann man dann OutOfMemoryErrors im Vorfeld aus dem Weg gehen.
Insgesamt hat man in Java nicht so viele try-catch-Blöcke, wie man vielleicht denken könnte. Die betreffen im Normalfall nämlich nur wenige Codebereiche: IO zum Beispiel oder auch Bereiche mit Reflection. Man sollte also eher sparsam mit Exceptions umgehen und sich immer fragen, ob es sich in einer Situation tatsächlich um eine echte Ausnahme handelt, auf die der Programmierer keinen Einfluss hat.