Quelles sont les différences entre les exceptions vérifiées et non vérifiées en Java, comment concevoir correctement le traitement des erreurs et quelles erreurs faut-il éviter en les utilisant ?

Réponse

En Java, les exceptions se divisent en exceptions vérifiées (checked) et exceptions non vérifiées (unchecked).

• Exceptions vérifiées — héritent de Exception, mais pas de RuntimeException. Le compilateur exige de les traiter explicitement par try-catch ou de les déclarer dans throws.
• Exceptions non vérifiées — héritent de RuntimeException. Le compilateur ne demande pas leur traitement obligatoire.

public void readFile(String file) throws IOException { /* ... */ } // vérifiée
public void divide(int a, int b) { int res = a/b; } // non vérifiée (ArithmeticException)

La principale subtilité — les exceptions vérifiées sont utilisées pour des situations attendues et récupérables (par exemple, les erreurs d'entrée-sortie), tandis que les exceptions non vérifiées le sont pour des erreurs logiques de programmation ou des situations critiques dont on ne peut pas se remettre (par exemple, NullPointerException).

Question piège

Question: Faut-il traiter ou déclarer dans throws une exception non vérifiée si votre méthode peut en lancer une ?

Réponse: Non. Le compilateur ne demande pas de vérifier ou de déclarer les exceptions non récupérables (unchecked). Leur traitement est à votre discrétion ; vous pouvez utiliser try-catch, mais il est plus courant de laisser "tomber" jusqu'au gestionnaire global.

public void foo() { throw new IllegalArgumentException(); } // Ne nécessite pas de traitement ou de déclaration

Exemples d'erreurs réelles dues à l'ignorance des subtilités du sujet

---

Histoire

Dans le projet d'API bancaire, lors du traitement des erreurs d'entrée-sortie, une RuntimeException était lancée au lieu de checked. Par conséquent, les clients n'étaient pas contraints de les traiter, ce qui entraînait un fonctionnement incorrect en cas de perte de connexion au serveur, et l'application "plantait" sans informer l'utilisateur.

---

Histoire

Un développeur a déclaré un nombre excessif de throws Exception dans les signatures de méthodes (par exemple, base de données), ce qui a contraint toutes les méthodes utilisées au-dessus à avoir soit try-catch, soit aussi throws. Cela a encrassé le code, a diminué sa lisibilité et a compliqué le refactoring.

---

Histoire

Dans l'un des microservices, toutes les exceptions étaient capturées avec un catch (Exception e) générique. Cela capturait également les exceptions non vérifiées (par exemple, NullPointerException), ce qui entraînait une "ignorance silencieuse" des erreurs critiques — le service fonctionnait avec des données incorrectes.