Gabi und Sascha
Kategorien : Alle | Berlin | Bücher | Fotografie | Java | Linkhalde | Weichware | Verfassung
[MANN IM VORDERGRUND LIESST MIT ÜBERGESCHLAGENEN BEINEN AUF EINER PARKBANK IN EINEM BUCH. DAS BUCH HAT ER SEHR DICHT VOR DEN AUGEN. SEINE HAARE UND SIND STRENG FRISIERT UND ER TRÄGT EINE STOFFHOSE. HINTER IHM WENDET SICH EINE FRAU MIT ROCK, HOCHHACKIGEN SCHUHEN UND EINER ART TURBAN ZUM GEHEN AB. DER HINTERGRUND IST UNSCHARF UND DAS BILD IN SCHWARZWEISS.]
Minsk - Janka Kupala Park
Hintergrund
Die Szene wirkt wie gestellt. Tatsächlich sassen die beiden aber nicht auf der selben Bank und hatten nichts miteinander zu tun. Beide passen von ihrem Äusseren so gar nicht in das junge Minsk. Sie wirken wie aus einer anderen Zeit.

Aufgenommen am 11. Mai 2011 im Janka Kupala Park in Minsk mit der Olympus E-P2 und dem Canon FD 50mm 1:1,4 bei Offenblende.

In Java existiert das sogenannte Konzept der checked exceptions. Jede Exception, die nicht vom Typ RuntimeException ist, muss in Methoden deklariert werden, wenn sie geworfen wird. Und sie muss explizit gefangen werden, wenn eine Methode, die die Exception deklariert, aufgerufen wurde. Alternativ kann die aufrufende Methode die Exception – oder einen generelleren Typen – fangen oder weiter werfen. Soweit so bekannt, so langweilig.

Problematisch wird es wenn Methoden Mengen solcher checked exceptions werfen oder in einem try-catch Block mehrere Methoden mit unterschiedlichen checked exception aufgerufen werden. Dann kann es zu elend langen catch Sequenzen kommen. Java 7 wird hier etwas Abhilfe schaffen. Trotzdem kann es nervig sein, sich durch die Exceptionwüsten zu arbeiten.

Der grösste Vorteil von checked exceptions ist meiner Meinung nach aber der dokumentierende Charakter. Dadurch, dass eine checked exception explizit in der Methode dokumentiert wird, weiss der Entwickler was ihn erwartet – und kann entsprechend handeln. Beispielsweise ist eine meiner Lieblingsexceptions die IOException. Sie dokumentiert, dass eine IO-Operation Probleme machen kann. Passiert dies, tritt ein Problem auf, kann ich als Entwickler oft noch versuchen zu reagieren. Ich kann beispielsweise versuchen noch einmal eine Datei anzulegen, in eine Datei oder auf einen Socket zu schreiben. Erst wenn dies ein paarmal nicht funktioniert hat, hat kann aufgegeben werden. Oder ein Subtyp der Exception besagt glasklar: hier geht nichts mehr.

Würde die IOException eine RuntimeException sein, dann muss sie nicht dokumentiert werden. Weder im Code in der Methodensignatur, noch in den Javadocs. Und genau diese Dokumentation wird dann auch ganz gerne einmal vergessen. Ist dies der Fall kann ich nur erahnen, dass ein IO Problem aufgetreten ist, um entsprechend zu reagieren oder ich muss auf Verdacht eine IOException fangen. Geholfen ist mir damit nicht viel.

Leider wird viel zu oft bei Exceptions überhaupt nicht reagiert und z.B. bei Datenbankoperationen stumpf ein Rollback durchgeführt. Das Exceptions signalisieren: versuch es noch einmal oder nimm einen alternativen Weg ist bei der Geschwindigkeit, in der heute Dinge entwickelt werden leider kaum zu vermitteln. Deswegen fehlt meistens eine entsprechende Strategie im Umgang mit Exceptions. Auf Exceptions nur mit einem totalen Abbruch zu reagieren ist ein nach-mir-die-Sintflut programmieren. Qualität kann so nicht entstehen. Ich denke, dass dies einer der Gründe ist, warum sich das Konzept der checked exceptions nicht durchgesetzt hat.