Exception Handling – Faustregel Checked oder Unchecked
Eine einfache Faustregel, wann man Checked oder Unchecked Exceptions verwendet.
Zwingt man Entwickler dazu, etwas Unnötiges zu tun,
werden sie etwas Dummes tun.
Dieser Satz wird oft dem Informatiker und Entwickler Jamie Zawinski [1] zugeschrieben, der unter anderem für seine Arbeit an frühen Internet-Softwareprojekten wie Netscape Navigator und Mozilla bekannt ist. Er meint damit Folgendes: Wenn Entwickler gezwungen werden, unnötige oder sinnlose Aufgaben zu erledigen, neigen sie dazu, unüberlegte Entscheidungen zu treffen oder schlecht strukturierten Code zu schreiben.
Genau dies ist auch der Fall, wenn in einer Schnittstelle Checked Exceptions verwendet werden, wo man besser Unchecked Exceptions verwendet hätte. Denn Checked Exceptions müssen behandelt werden. Falsch verwendet zwingen sie dazu, unnötige Dinge zu tun.
Aber welche dummen Dinge könnte ein Programmierer tun, wenn Checked Exceptions verwendet werden, wo sie keinen Sinn machen?
- Stillschweigendes Ignorieren von Exceptions
- Verschmutzung der Methodensignatur (Anhäufung vieler Exceptions unterschiedlicher Abstraktionsebenen in der throws-Klausel)
- „throws Exception“ in der Methodensignatur (um die Anhäufung verschiedener Exceptions zu vermeiden)
- „catch Exception“ (warum dies keine gute Idee ist, kann man hier lesen)
Doch die Entscheidung zwischen Checked und Unchecked scheint vielen schwer zu fallen.
Daher möchte ich hier eine Faustregel teilen, die ich auf Stackoverflow gefunden habe und mir selbst sehr geholfen hat [2]:
Faustregel: Checked oder Unchecked?
Checked Exceptions nur für Fehler, die …
- sowohl vorhersagbar
- als auch unvermeidbar sind,
- und bei denen der Client eine vernünftige Behandlungsmöglichkeit hat, um die Fehlersituation während der Laufzeit zu beheben.
Dies ist erstaunlich selten der Fall.
Wichtig ist, dass Checked / Unchecked auf jeder Abstraktionsebene evaluiert werden muss. Gegebenenfalls müssen dazu Exceptions gefangen und konvertiert werden, je nachdem, was an der Stelle für die Aufrufer sinnvoll scheint.
Beispiel für die Verwendung einer Checked Exception
Use Case: Anlage einer Datei:
- Es ist vorhersagbar, dass eine Datei mit demselben Namen von mehreren Prozessen angelegt werden könnte.
- Diese Situation ist unvermeidbar. Denn auch wenn der Prozess geprüft hat, ob die Datei bereits vorhanden ist, könnte sie zwischen Prüfung und Anlage von einem anderen Prozess angelegt werden.
- Es gibt eine vernünftige Behandlungsmöglichkeit, nämlich automatisch den Dateinamen um Zähler ergänzen oder Benutzer nach neuem Dateinamen / Überschreiben fragen.
Fazit
Checked Exceptions sollten nur für Fehler verwendet werden, die vorhersagbar, unvermeidbar und vom Client während der Laufzeit vernünftig behandelbar sind. Auf jeder Abstraktionsebene muss evaluiert werden, in welchen Fällen welche Art der Exception für den Aufrufenden hilfreich ist. Gegebenenfalls müssen dazu Exceptions gefangen und konvertiert werden.
[1] Webseite von Jamie Zawinski
[2] When to choose checked and unchecked exceptions – Stackoverflow.com
Bildnachweis:
– Das Titelbild zur Blogserie „Exception Handling“ basiert auf einer Grafik von mohamed_hassan auf Pixabay.
– Die Illustration „Faust“ stammt ursprünglich von DreamDigitalArtist auf Pixabay.
