Comment tranchez-vous entre une exception checked et unchecked, et comment gérez-vous les exceptions dans un service ?

N'utilisez une exception checked que si l'appelant peut réellement s'en remettre et que vous voulez que le compilateur force une décision ; utilisez unchecked pour les erreurs de programmation et pour les défaillances que personne plus haut ne peut corriger. En pratique, le Java moderne penche vers unchecked, en enveloppant les défaillances bas niveau dans une exception métier qui porte du contexte, traitée une seule fois à une frontière comme un gestionnaire d'exceptions qui la traduit en réponse.

Mon test, c'est de savoir si un appelant peut en faire quelque chose d'utile. Un paiement refusé par le prestataire est un résultat métier légitime, donc c'est soit une exception checked, soit plus souvent un type résultat. Un argument null ou une connexion à la base qui échoue n'est pas quelque chose que le code appelant peut corriger, donc c'est unchecked. Dans les services j'utilise surtout des exceptions métier unchecked, en enveloppant la cause sous-jacente pour que la trace de pile survive, et en ajoutant les identifiants que je voudrai dans le log, comme l'id de commande, puisqu'une exception SQL nue trois couches plus bas ne me dit rien. Le traitement se fait une fois, à une frontière : dans Spring c'est un gestionnaire d'exceptions qui associe chaque exception métier à un code de statut et à un corps de réponse, ce qui garde les contrôleurs propres. Ce que je conteste en revue, c'est attraper Exception largement, attraper et logguer puis continuer comme si de rien n'était, et les blocs catch vides. J'utilise aussi try-with-resources partout plutôt que des blocs finally, parce que les exceptions supprimées et les échecs de fermeture sont gérés correctement sans effort.