Zusammenfassung der wichtigsten Punkte
- Obwohl Javas Checked Exceptions in der Community häufig kritisiert werden, bieten sie erhebliche Vorteile in Bezug auf Typsicherheit.
- Sie stellen konzeptionell einen Typsicherheitsmechanismus bereit, der Rusts
Result<T, E> oder Haskells Either a b ähnelt.
- Checked Exceptions drücken potenzielle Fehlermöglichkeiten explizit in der Methodensignatur aus und erzwingen so Fehlerbehandlung über das Typsystem.
Vorteile von Checked Exceptions
- Sie bieten Typsicherheit, indem zur Compile-Zeit geprüft wird, ob Ausnahmen behandelt werden.
- Durch die explizite Angabe möglicher Ausnahmen mit der
throws-Klausel in der Methodensignatur werden sie zu einem Teil des API-Vertrags.
- Sie bieten einen komfortablen Mechanismus, bei dem Ausnahmen nach bloßer Deklaration automatisch weitergereicht werden.
- Anders als in Rust ist bei jedem Aufruf keine zusätzliche Syntax wie der
?-Operator nötig.
Probleme von Checked Exceptions
- In Aufrufketten entsteht übermäßiger Boilerplate-Code.
- Es mangelt an Kompatibilität mit funktionaler Programmierung wie Lambdas und der Stream-API, die seit Java 8 eingeführt wurden.
- Das Hinzufügen neuer Ausnahmen zu Interfaces erschwert die Weiterentwicklung von APIs, weil dadurch die Kompatibilität gebrochen wird.
- Sie können Anti-Patterns begünstigen, bei denen Ausnahmen ignoriert werden.
Verbesserungsvorschläge
- Funktionale Interfaces verbessern, damit Lambdas Checked Exceptions deklarieren können.
- Unterstützung für generische Exception-Typen in der
throws-Klausel ergänzen.
- APIs erweitern, damit Checked Exceptions in funktionalen Kontexten besser behandelt werden können.
- Bessere Integration mit den APIs von
Optional<T> und Stream<T>.
Vergleich mit anderen Sprachen
- Rust: bietet einen expliziten Mechanismus zur Fehlerbehandlung mit
Result<T, E> und dem ?-Operator.
- Kotlin: hat alle Exceptions zu Unchecked Exceptions gemacht, bietet aber funktionale Konstrukte wie
runCatching.
- Scala: unterstützt funktionale Fehlerbehandlung durch monadische Typen wie
Try[T] und Either[A, B].
Fazit
- Checked Exceptions sind eine missverstandene innovative Funktion von Java, die neu bewertet werden sollte.
- Statt sie vollständig aufzugeben, wäre es sinnvoll, sie so zu verbessern, dass sie gut mit modernen Java-Funktionen zusammenspielen.
- Es besteht Potenzial, sie unter Beibehaltung des bestehenden Paradigmas in Richtung praktischer Problemlösung weiterzuentwickeln.
- Wichtig ist, ein Gleichgewicht zwischen Typsicherheit, prägnantem Code und Flexibilität zu finden.
1 Kommentare
Es fühlte sich an, als würde eine Debatte wiederholt, über die schon seit mehr als einem Jahrzehnt gesprochen wird. Es wirkt wie die Behauptung, dass Exceptions genauso wertvoll sind wie Typen, und ich möchte darauf antworten, dass Typen allein ausreichen.