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).