@Teletambi: Dieser Thread war bereits als gelöst gemeldet.
Trotzdem weisst du auf eine sehr wichtige Sache hin.
Ist mir damals entgangen, wobei ich mich in dem Punkt "external Ressourcen schliessen" bisher für paranoid gehalten habe.
Schliessen der Connection im finally (oder meine traditionelle Lösung s.u.) finde ich auch besser, weiss nicht, warum ich damals nicht darauf hingewiesen habe. Das wurde hier am Ende des try und im catch Block geschlossen, was nicht perfekt ist, hier aber offenbar ausreichend.
Danke aber für deinen Hinweis, weil du in gewissen Punkten sicher recht hast.
Jede Exception *einzeln* zu catchen halte ich hingegen für unnötig.
Schliesslich haben Exceptions in Java eine gewisse Vererbungshierarchie, die man sich zu Nutze machen kann.
Wenn du eine gewisse Menge an Funktionalität/per Stunde programmierst, hat man in der Praxis keine Zeit, jede Exception einzeln zu catchen. Statt dessen sollte man sich Gedanken machen, wo spezifisches Exception Handling Sinn macht. Wo nicht, sollte man die Superklassen verwenden (s.u.)
In Java gibt es 2 Arten von Exceptions.
Checked und Unchecked.
Die Checked sind die, wo der Compiler immer anmeckert, dass man diese Exception abfangen muss. Alle checked Exceptions erben von der Klasse java.lang.Exception.
Unchecked Exceptions müssen nach Meinung des Compilers dagegen nicht per catch abgefangen werden. Das sind oft exception, die mit dem Wissen des Compilers eigentlich immer auftreten können. Z.B. NullPointerException. Der Compiler weiss nicht, ob später bei der Ausführung des Programms eine Referenz auf ein Objekt weist oder nicht.
Um sicher zu gehen, dass ein catch-Block für alle Arten von Exceptions zuständig ist, kann man java.lang.Throwable nutzen. Throwable ist die Superklasse von Exception, RuntimeException und Error ist (wobei RuntimeException und Error Superklassen aller unchecked Exceptions sind).
Wenn man z.B. mit externen Ressourcen arbeitet, kann es imho Sinn machen mit Throwable zu arbeiten. Oder man schliesst sie eben im finally.
Über dem Throwable können dann spezifischere Exceptions abgefangen werden.
z.B.:
try {
...
} catch (NotesException e) {
... do stuff ..
}
catch (SQLException e) {
... do stuff ..
}
catch (Throwable t) {
/* würde man hier, in allen darüberliegenden catches und im try die Connections schliessen wäre das safe. Man kann hierfür eine extra Methode vorsehen. So mach ich das immer aus Gewohnheit. */
... do stuff ...
} finally {
/* würde man hier die Connections schliessen und im try nicht wäre das auch safe und weniger Tipparbeit. Vielleicht sollte ich meine Gewohnheit ändern. Wobei ich für DB-Zugriff Frameworks (s.u.) nutze, wo ich kann: Heisst überall ausser in Java in Notes. */
}
In der Tat ist gerade das Exception-Handling und auch Probleme mit stalled Connections (die man in den Griff kriegen kann) Punkte, die oft an der Architektur von JDBC kritisiert worden sind.
Dies ist ein eher unwichtiger Grund, warum die Leute so gerne Frameworks wie Hibernate oder ibatis SQLMaps statt low-level JDBC arbeiten, da diese Frameworks diese und andere Probleme schon gelöst haben.
Ach ja. Und bei OutOfMemoryError extends java.lang.Error wird natürlich weder das catch noch das finally aufgerufen.
Gruß Axel
