Comment fonctionne la gestion des exceptions et la distinction vérifié/non vérifié ?

Question

Accepted Answer

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.

## La structure de base

```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.

## La hiérarchie des exceptions

```text
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...
```

## Les exceptions vérifié — imposées par le compilateur

```java
// 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.

## Les exceptions non vérifiées — runtime, non imposées

```java
// 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.

## try-with-resources (nettoyage automatique)

```java
// 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
```

## Bonnes pratiques

```text
✓ 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)
```

## Pourquoi c'est important

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.