Ich kann es nicht mehr sehen: Try-Catch-Throw, Try-Catch-Throw. Gecheckte Exceptions sind so gut wie tot, helfen wir bei der schnellen Beerdigung. Java bietet von Haus aus ein kleines aber feines Portfolio an Runtime-Exceptions. Diese decken fast alle Fälle des täglichen Bedarfs ab und belästigen den Aufrufer nicht mit möglichen Fehlern, die er ohnehin nicht ordentlich behandeln kann…
IllegalArgumentException
Passt immer, wenn die Argumente, die an Konstruktor oder Methode übergeben wurden, nicht den Erwartungen entsprechen.
NullPointerException
Keine Spezialisierung der IllegalArgumentException, dennoch ein naher Verwandter: Teilt mit, dass ein Argument null ist, obwohl dies so nicht vorgesehen ist.
IllegalStateException
Wird immer dann benötigt, wenn Methoden nur in einer speziellen Reihenfolge verwendet werden dürfen und ein Abweichen zu einem ungültigen Zustand führen kann. Besser ist es natürlich, solche unsichtbaren Reihenfolgezwänge zu vermeiden. Möglich ist dies jedoch nicht immer.
IndexOutOfBoundsException
Der Klassiker für alles, was einen potentiell ungültigen Index haben kann.
StringIndexOutOfBoundsException
Eine spezielle Variante für die Manipulation von Strings.
UnsupportedOperationException
Nicht immer sind Interfaces so sauber und feingranular aufgebaut, dass man wirklich jede vorgegebene Methode implementieren kann. Diese Exception macht dies unmissverständlich deutlich. Dennoch eine Notlösung, denn die Erkenntnis zur Laufzeit ist eigentlich etwas spät.
Checked Exceptions sind tot
Die klassischen, gecheckten Java-Exceptions wirken heute wie ein Relikt aus früheren Zeiten. Die Java-Macher scheinen dem zuzustimmen und bieten eine Auswahl an ungecheckten Runtime-Exceptions, die fast alle Problemfälle abdeckt.
Das Pflegen unzähliger, hochspezialisierter Exceptions in einem Software-Projekt wirkt heute nicht zeitgemäß: Ausnahmen sollen keine Kontrollstrukturen ersetzen; in den meisten Fällen sind es schlicht fehlerhafte Zustände, die vor dem Programmabbruch geloggt werden müssen. Ein falsch eingegebenes Passwort ist keine Ausnahme, sondern eher die Regel; etwas das andauernd passiert: Wird eine Exception regelmäßig geworfen, wird das Exception-Konzept missbraucht und sollte durch Bedingungen ersetzt werden.
Wichtig sind präzise und ausführliche Meldungen, die das Problem und mögliche Ursachen beschreiben. Fehler lassen sich somit effizient beseitigen und vermeiden dank ihrer Fokussierung auf die Laufzeit das oft übliche Fangen-Kapseln-und-Weiterwerfen, wie es bei gecheckten Exceptions üblich ist.
Dem kann ich so nicht zustimmen. Was möchte man auf keinen Fall an den Kunden ausliefern?
Eine Anwendung, die sich sang- und klanglos beendet. Was passiert, wenn eine RuntimeException nicht gefangen wird.
Vermeidet man Checked Exceptions, erhöht dies im Gegenzug den Test- und Entwicklungsaufwand.
Die Kunst besteht darin, Exceptions als Architekturelement sinnvoll einzusetzen, und frühzeitig die Vielzahl technischer Exceptions auf ein Minimum fachlich begründeter Checked Exceptions zu reduzieren.
Natürlich sollte eine Anwendung nicht sang- und klanglos abschmieren, hier muss generell gefangen, geloggt und eine Interner-Fehler-Meldung ausgegeben werden. Das eine hat nichts mit dem anderen zu tun. Und was ich noch weniger will: Durch Fehlermeldungen die Interna meiner Anwendung nach außen tragen, um sie angreifbar zu machen.
Eine gute objektorientierte Architektur ist in meinen Augen mit checked Exceptions nur leider kaum möglich, da sie dir mit Throw-Catch-Throw in jeder Methode den Code oder durch den Bruch der Kapselung die gesamte Architektur versauen. Ich wüsste jedenfalls nicht wie das aussehen soll.