Ad-Hoc Exception Handling

Gerne nutze ich während des Entwicklungs die Fähigkeit moderner Entwicklungsumgebungen automatisch try-catch Blöcke zu erzeugen. Man möchte schließlich die Funktionalität fertig kriegen.

Normalerweise kommt dabei sowas raus:

try{
  doSomthingInteresting();
} catch (Exception e) {
  //todo: error handling
   e.printStackTrace();
}

Der Nachteil ist offensichtlich. Der Tag an dem man alle Todos abarbeitet kommt nie. Irgendwann tritt der Fehler auf. Die Exception wird gefangen, die Anwendung läuft weiter und der Fehler bringt die das Programm im weiteren Verlauf ins Straucheln. Die Standardausgabe ist womöglich nicht verfügbar, außerdem könnten mittlerweile weitere Exceptions aufgetaucht sein – der Stoff aus dem ruinierte Nächte gemacht werden.

Ich schlage stattdessen folgendes Schema vor:

try{
  doSomthingInteresting();
} catch (Exception e) {
  throw new RuntimeException(e);
}

Die Exception wird so nicht verschluckt, aber zunächst muss sie nicht behandelt werden. Dieses Template kann man auch den gängigen IDEs beibringen.

Um die Fehlerdiagnose weiter zu vereinfachen bietet es sich an der RuntimeException noch eine gute Message mitzugeben:

try{
  doSomthingInteresting();
} catch (Exception e) {
  throw new RuntimeException("Could not do InterestingStuff",e);
}

Eine Verfeinerung des Ansatzes besteht darin bestimmte eigene Runtime Exceptions zu werfen und diese außen im Eventloop (oder Request) zu fangen und entsprechend zu reagieren (Rollback, Fehlermeldung).

This entry was posted in Java. Bookmark the permalink.

0 Responses to Ad-Hoc Exception Handling

  1. kiu says:

    Imho sollte man sich beim Entwickeln um Performance generell keine Gedanken machen (zumindest auf solch einer niedrigen Ebene).

    “As a rule, 90 percent of a program’s excution time is spent executing 10 percent of the code.”

    Wenn man ein funktionierendes Programm hat, kann man am Ende einen Profiler drueberjagen (java -prof helloworld) und die Bottlenecks identifizieren.

  2. felix says:

    Prinzipiell ist das richtig und die Messungen hatte ich unter anderem vorgenommen, um das zu zeigen.
    Denn Objekterzeugung ist billig und Methodenaufrufe auch, man kann hier also getrost ein schönes Design machen.

    Allerdings muss beachtet werden, dass bestimmte Operationen _sehr_ viel teurer sind. Insbesondere bei verteilten Anwendungen muss man da schon beim Design ein wenig aufpassen.

    Das ist alles relativ klar. Aber es ist erschreckend wie viele Leute als IT-Spezialisten rumlaufen und noch nie einen Profiler angeschmissen haben.
    Leute die gerne einmal mehr zur DAtenbank laufen, “weil die schneller sortiert”.

    Übrigens auch unverschämt ist JProbe. Ein sauteures Tool, das eine vollkommen kaputte Benutzeroberfläche hat – Swing at its worst.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.