Java gère les erreurs avec try/catch/finally, et distingue de manière unique les exceptions vérifié (qui doivent être déclarées ou gérées) des exceptions non vérifiées (runtime, non imposées). Comprendre cette distinction est central à la gestion des erreurs en Java.
try {
FileReader f = new FileReader("file.txt"); // may throw IOException
// ... use it ...
} catch (FileNotFoundException e) {
System.out.println("not found: " + e.getMessage()); // specific first
} catch (IOException e) {
System.out.println("io error"); // broader after
} finally {
System.out.println("always runs — cleanup"); // runs no matter what
}
finally s'exécute toujours (nettoyage), même si une exception est levée ou si une déclaration return se produit.
Throwable
├── Error — serious JVM problems (OutOfMemoryError) — don't catch
└── Exception
├── RuntimeException → UNCHECKED (not enforced by the compiler)
│ NullPointerException, IllegalArgumentException, IndexOutOfBounds...
└── (other Exceptions) → CHECKED (compiler enforces handling)
IOException, SQLException...
// MUST either catch it or declare `throws` — the compiler won't let you ignore it
public void readFile() throws IOException { // declare it
Files.readAllLines(Paths.get("file.txt")); // throws checked IOException
}
Les exceptions vérifié (IOException, SQLException) représentent des conditions récupérables et attendues (un fichier manquant, une défaillance réseau). Le compilateur vous force à les gérer ou les déclarer — rendant la gestion des défaillances externes explicite.
// NOT required to declare or catch — usually indicate PROGRAMMING BUGS
String s = null;
s.length(); // NullPointerException (unchecked)
int x = arr[10]; // ArrayIndexOutOfBoundsException (unchecked)
Integer.parseInt("abc"); // NumberFormatException (unchecked)
Les exceptions non vérifiées (sous-classes de RuntimeException) signalent généralement des erreurs de programmation — vous corrigez le bug plutôt que de le catch partout. Le compilateur ne force pas la gestion.
// resources implementing AutoCloseable are closed automatically
try (FileReader f = new FileReader("file.txt")) {
// use f
} // f.close() called automatically, even on exception — no finally needed
✓ Catch specific exceptions, not bare Exception
✓ Use try-with-resources for files/connections (auto-close)
✓ Don't swallow exceptions silently (empty catch blocks)
✓ Throw meaningful exceptions; include context in messages
✓ Custom exceptions extend Exception (checked) or RuntimeException (unchecked)
Une gestion robuste des erreurs est essentielle, et la distinction vérifié/non vérifiée de Java est une caractéristique définissante (et débattue) qu'il vaut la peine de comprendre profondément.
Les exceptions vérifié imposent une gestion explicite des défaillances externes attendues (I/O, DB) — promouvoir la fiabilité mais parfois critiquée comme verbeuse ; les exceptions non vérifiées représentent des bugs à corriger plutôt qu'à catch systématiquement.
Connaître la hiérarchie, quand chaque type s'applique, la sémantique de try/catch/finally, et try-with-resources moderne pour le nettoyage automatique est fondamental pour écrire du Java correct et fiable — et pour concevoir vos propres exceptions de manière appropriée.
La distinction façonne la manière dont les API Java sont conçues et est un sujet fréquent d'entretien et d'examen du code.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don