Réponse

Le mécanisme de gestion des exceptions via try-catch-finally a été ajouté en Java dès le début de la développement du langage. L'objectif principal est de garantir une gestion structurée des erreurs, en séparant le code de travail et le code de gestion des erreurs.

Problème : tout comportement anormal ou erroné entraîne le lancement d'une exception. Sans try-catch, il est uniquement possible de transmettre cela plus haut dans la pile d'appels. Avec cette approche, le programme peut se terminer de manière inattendue.

Solution — utilisation de try { } catch { } finally { }, ce qui permet de traiter les exceptions attendues et d'exécuter systématiquement les actions de terminaison (libération des ressources, fermeture des fichiers, annulation des transactions).

Exemple de code :

try {
    FileInputStream fin = new FileInputStream("test.txt");
    int data = fin.read();
} catch (IOException e) {
    System.out.println("Erreur lors du travail avec le fichier : " + e.getMessage());
} finally {
    fin.close();
}

Caractéristiques clés :

Le bloc try contient du code potentiellement erroné
catch intercepte et gère les exceptions
finally s'exécute toujours, même en cas de return/exception

Questions pièges.

Le finally peut-il ne pas être exécuté ?

Oui, si System.exit() est appelé à l'intérieur du bloc, si le processus se termine de manière inattendue, ou si la JVM « tombe » physiquement.

Peut-on utiliser try-catch sans finally ?

Oui, le bloc finally n'est pas obligatoire. Mais s'il est nécessaire de libérer des ressources, il est généralement utilisé. Depuis Java 7, il existe le try-with-resources.

Que se passe-t-il si une exception se produit dans finally ?

Si une nouvelle erreur se produit dans finally, elle « écrasera » l'originale (si elle n'est pas interceptée séparément), ce qui peut masquer des problèmes.

try { throw new RuntimeException("échec dans try"); }
finally { throw new RuntimeException("échec dans finally"); }
// Trace de pile final — uniquement "échec dans finally"

Erreurs typiques et anti-modèles

Ignorer l'exception (catch(Exception e) {} vide)
Relancer sans indiquer la cause (throw e; sans new Exception(e))
Interrompre finally (retourner ou lancer un nouveau Exception)

Exemple de la vie réelle

Cas négatif

Dans un projet, le bloc finally contenait du code qui pouvait lui-même lancer IOException. En cas d'erreur dans try, l'exception originale était complètement perdue, rendant le diagnostic des erreurs très difficile.

Avantages :

Libération garantie des ressources

Inconvénients :

Masquage des erreurs
Débogage difficile

Cas positif

Au lieu de finally, l'équipe est passée au try-with-resources. Chaque ressource implémente AutoCloseable, la libération se fait automatiquement, et les exceptions sont journalisées dans les logs sous forme d'erreurs propres.