# Exceptions et gestion des erreurs en programmation objet Informatique de gestion · Bachelor 2 > Lever, propager et traiter les exceptions : try/catch/finally, exceptions vérifiées et robustesse. ## Introduction Une exception est un objet qui signale qu'une situation anormale empêche une méthode de remplir son contrat : fichier introuvable, montant négatif, connexion à la base de données interrompue. Plutôt que de retourner des codes d'erreur que l'appelant risque d'ignorer, les langages objet comme Java, C# ou Python interrompent le flux normal et remontent la pile d'appels jusqu'à trouver un bloc capable de traiter le problème. Une bonne gestion des erreurs distingue les fautes de programmation (argument nul, indice hors limites), que l'on corrige dans le code, des erreurs prévisibles de l'environnement (réseau, fichier, saisie), que l'on anticipe. Elle garantit aussi la libération des ressources (fichiers, connexions) via finally ou des constructions du type try-with-resources, et préserve la cohérence des objets : un objet ne doit jamais rester dans un état invalide après un échec. En informatique de gestion, cette discipline est décisive : une facture partiellement enregistrée ou une connexion jamais fermée dans une application de facturation se paient en incohérences comptables et en pannes difficiles à diagnostiquer. ## Objectifs d'apprentissage - Distinguer erreur de programmation, erreur d'environnement et erreur métier - Utiliser try, catch et finally pour traiter une exception et libérer les ressources - Différencier exceptions vérifiées et non vérifiées et justifier le choix - Concevoir une hiérarchie d'exceptions métier avec des messages exploitables - Éviter les anti-patrons : catch vide, capture trop large, exceptions pour le flux normal ## Concepts clés - **Propagation** : Si une méthode ne traite pas l'exception, elle remonte à son appelant, puis à l'appelant de celui-ci, jusqu'à un bloc catch adapté ou jusqu'à l'arrêt du programme avec sa trace de pile. - **Exceptions vérifiées et non vérifiées** : En Java, les exceptions vérifiées (checked) doivent être déclarées ou capturées ; les non vérifiées (RuntimeException et dérivées) ne l'exigent pas. C# et Python n'ont pas cette distinction obligatoire. - **Libération des ressources** : Le bloc finally s'exécute que l'exception survienne ou non ; try-with-resources (Java), using (C#) et with (Python) automatisent la fermeture. - **Exception métier** : Classe dédiée (ex. SoldeInsuffisantException) qui exprime une règle du domaine, porte des informations utiles et reste indépendante des détails techniques. ## Conclusion Gérer correctement les exceptions, c'est concevoir le chemin d'échec avec autant de soin que le chemin nominal : détecter tôt, nommer l'erreur dans le vocabulaire du domaine, libérer les ressources et laisser les objets cohérents. Pour un système de gestion, la robustesse se mesure à la manière dont il se comporte quand quelque chose tourne mal. Les bons réflexes (pas de catch vide, pas de capture trop large, journalisation unique) font gagner un temps considérable en exploitation. ## Cartes ### Qu'est-ce qu'une exception ? Un objet qui signale une situation anormale et interrompt le flux normal d'exécution pour remonter la pile d'appels jusqu'à un gestionnaire. ### À quoi sert le bloc finally ? À exécuter du code de nettoyage (fermer un fichier, une connexion) que l'exception se produise ou non. ### Pourquoi un catch vide est-il un anti-patron ? Il avale l'erreur sans trace : le programme continue dans un état potentiellement invalide et le diagnostic devient presque impossible. ### Quelle différence entre exception vérifiée et non vérifiée en Java ? La vérifiée doit être capturée ou déclarée (throws) ; la non vérifiée (RuntimeException) n'impose rien au compilateur. ### Quand lever une exception plutôt que retourner un code ? Quand la méthode ne peut pas remplir son contrat : le code d'erreur peut être ignoré, l'exception ne peut pas passer inaperçue. ### Pourquoi éviter de capturer Exception de façon générale ? On masque des erreurs imprévues (dont des bugs) et on traite de la même manière des situations qui demandent des réponses différentes. ### Que signifie « échouer vite » (fail fast) ? Vérifier les préconditions dès l'entrée d'une méthode et lever immédiatement une exception, plutôt que laisser l'erreur se manifester plus loin. ### Pourquoi encapsuler une exception technique dans une exception métier ? Pour ne pas exposer les détails d'implémentation (SQL, réseau) aux couches supérieures, tout en conservant la cause d'origine pour le diagnostic. ### Que doit-on faire de l'état d'un objet après une exception ? Garantir qu'il reste cohérent : soit l'opération est entièrement réalisée, soit l'objet reste inchangé (garantie forte). ### Pourquoi ne pas utiliser les exceptions pour le flux normal ? Elles sont coûteuses, rendent le code difficile à lire et signalent des cas exceptionnels, pas des branches ordinaires comme « fin de liste ». ## Glossaire - **Exception** : Objet signalant une situation anormale qui interrompt le flux normal d'exécution. - **Trace de pile (stack trace)** : Liste des appels de méthodes actifs au moment où l'exception a été créée. - **Précondition** : Condition que l'appelant doit respecter pour qu'une méthode fonctionne correctement. - **try-with-resources** : Construction Java fermant automatiquement les ressources ouvertes dans le bloc try. - **Exception métier** : Exception exprimant la violation d'une règle du domaine fonctionnel. - **Chaînage d'exceptions** : Conservation de l'exception d'origine comme cause d'une nouvelle exception. https://ruvy.ch/decks/-P5Ctie2LOE_fPFvIbxR