Résumé des points clés
- Les exceptions vérifiées de Java, bien qu’elles soient largement critiquées dans la communauté, offrent de solides avantages en matière de sûreté des types.
- Elles fournissent un mécanisme de sûreté des types conceptuellement proche de
Result<T, E> en Rust ou de Either a b en Haskell.
- Les exceptions vérifiées expriment explicitement dans la signature des méthodes la possibilité d’un échec potentiel, imposant ainsi la gestion des erreurs via le système de types.
Avantages des exceptions vérifiées
- Elles apportent une sûreté des types en vérifiant à la compilation si les exceptions sont correctement traitées.
- La possibilité d’exception est explicitement déclarée dans la signature de la méthode via une clause
throws, ce qui en fait une partie du contrat de l’API.
- Elles offrent un mécanisme pratique où les exceptions se propagent automatiquement dès lors qu’elles sont déclarées.
- Contrairement à Rust, aucune syntaxe supplémentaire comme l’opérateur
? n’est nécessaire à chaque appel.
Problèmes des exceptions vérifiées
- Elles génèrent un excès de code boilerplate dans les chaînes d’appels.
- Elles s’intègrent mal avec la programmation fonctionnelle, notamment les lambdas et la Stream API introduites depuis Java 8.
- Ajouter une nouvelle exception à une interface casse la compatibilité, ce qui complique l’évolution des API.
- Elles peuvent encourager des antipatterns consistant à ignorer les exceptions.
Pistes d’amélioration
- Améliorer les interfaces fonctionnelles afin que les lambdas puissent déclarer des exceptions vérifiées.
- Ajouter la prise en charge de types d’exception génériques dans les clauses
throws.
- Étendre les API pour mieux gérer les exceptions vérifiées dans les contextes fonctionnels.
- Mieux les intégrer avec les API
Optional<T> et Stream<T>.
Comparaison avec d’autres langages
- Rust : fournit un mécanisme explicite de gestion des erreurs avec
Result<T, E> et l’opérateur ?.
- Kotlin : a rendu toutes les exceptions non vérifiées, mais propose des structures fonctionnelles comme
runCatching.
- Scala : prend en charge la gestion fonctionnelle des erreurs via des types monadiques comme
Try[T] et Either[A, B].
Conclusion
- Les exceptions vérifiées sont une fonctionnalité innovante et mal comprise de Java, qui mérite d’être réévaluée.
- Plutôt que de les abandonner complètement, il serait préférable de les améliorer pour qu’elles s’accordent mieux avec les fonctionnalités modernes de Java.
- Elles peuvent évoluer vers une résolution pragmatique des problèmes tout en conservant le paradigme existant.
- Il est important de trouver un équilibre entre sûreté des types, concision du code et flexibilité.
1 commentaires
J’ai eu l’impression de répéter un débat dont on parle déjà depuis plus d’une dizaine d’années. C’est un peu comme soutenir que les exceptions ont autant de valeur que les types, et j’aimerais répondre que les types suffisent.