genervt, dass man in Java manche Exceptions abfangen muss...

[flaite]

... diese gezwungen try-catch ... die Mehrheit sieht das übrigens so. Auch unter erfahrenen Java Entwicklern sind diese CheckedExceptions (z.B. NotesException) umstritten.

In Java gibt es 3 Typen von Exceptions/Errors: Exception/Error/RuntimeException.
Klassen, die von Error erben, behandeln tiefe Systemprobleme wie z.B. JVM hat nicht genug Speicher, nach denen die Anwendung eh nicht mehr wiederbelebt werden kann. Anwendungsentwickler schreiben normalerweise nicht solche Error-Klassen, um auf diese System-Probleme zu reagieren. Diese Exceptions sollen auch nicht abgefangen werden, da sie quasi überall auftreten können.
Bleiben noch Exception und RuntimeException. Der Aufruf von Methoden die Exceptions werfen, benötigen ein try-catch (checked exceptions) (z.B. NotesException). RuntimeException nicht! (unchecked exceptions).

Relativ lange Zeit galt die Idee von checked exception als gutes engineering. Der Anwendungsprogrammierer hatte bei den Aufruf von Methoden einen Hinweis darauf, welche Exceptions auftreten  können und das kann wirklich sinnvoll sein. Er kann dann code schreiben, um drauf zu reagieren. So weit die Theorie. In der Praxis hat sich aber aus verschiedenen Gründen herausgestellt, dass dieses Konzept
a) viele unter Zeitdruck arbeitenden Anwendungsprogrammierer überfordert. Mit wenigen Ausnahmen wie Ralph oder Sanjou ist auch das ExceptionHandling des hier geposteten Code oft ein bischen beängstigend. Exception Handling ist oft sehr schlecht ausgeführt. Manchmal betrifft das leider sogar oft benutzte openSource Bibliotheken.
b) zu schwer lesbaren Code mit vielen try-catch-finally Blöcken und
c) Abhängigkeiten im Code schaffen, die die Austauschbarkeit von Subsystemen behindern.

Z.B. ist das springframework schon 2002 dazu übergegangen für Anwendungsentwickler leichter handhabbare unchecked exceptions zu verwenden. Und mittlerweile wird das immer stärker eingesetzt. Selbst EJB3 verzichtet auf einen noch in EJB2 stark verbreiteten Exception-Typ namens RemoteExceptions. Groovy benutzt auch keine checked Exceptions. MS.NEt übrigens auch nicht, obwohl deren Exception-Handling ansonsten sehr ähnlich wie in Java ist. In .NET ist eben alles eine RuntimeExcpetion.

Java Exception Handling find ich besser als in VB oder LotusScript. Aber mit checked Exception ist Sun in den 90ern möglicherweise einen Schritt zu weit gegangen. Was natürlich nicht heisst, dass man das jetzt als Anwendungsprogrammierer mittels Brutalo-Vereinfachern wie try {} catch(Throwable t) {} einfach ausradieren könnte, weil genau das führt zu Problemen, dass die Ursache von Fehlern einfach nicht mehr im Zugriff ist.

Der relativ berühmte Neil Gafter hat jetzt in seinem Blog gefragt, was die Leute denn jetzt von checked Exceptions halten. Da gibts viele Kommentare: http://gafter.blogspot.com/2007/05/removing-language-features.html

Persönlich find ich manche Tage checked exceptions gut und andere Tage voll nervig.