Le terme exception est un raccourci pour la phrase "evénement exceptionnel". > _Definition_: An _exception_ is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions. > > — https://dev.java/learn/exceptions/what-is-an-exception/#intro Quand une erreur exceptionnelle a lieu dans une méthode, celle-ci crée un objet et l'envoie au système d'exécution. Cet objet appelé une exception contient des informations sur l'erreur : type de l'erreur, l'état du programme quand l'erreur est survenue). On appèle **lever une exception** (throw an exception) ce mécanisme de création d'un objet d'exception et de le remonter au système d'exécution. Après que la méthode ait levé une exception, le système d'exécution tente d'en faire quelque chose pour le traiter. Si rien n'est fait, le programme crash. La pile d'appel ![[image-3.png|320x332]] Source : https://dev.java/learn/exceptions/what-is-an-exception/#intro A la recherche d'un exception handler dans la pile d'appel ![[image-4.png|320x246]] > Source : https://dev.java/learn/exceptions/what-is-an-exception/#intro ## 3 familles d'exceptions - `Error` : des erreurs externes à l'application qu'on ne peut pas anticiper - `Exception` : aussi appelées Checked exceptions : des cas exceptionnels qui sont documentés et doivent être anticipés et gérés - `RuntimeException` : aussi appellées Unchecked exceptions : peuvent arriver à l'intérieur de l'application ### `Error` Des erreurs externes à l'application qu'on ne peut pas anticiper ### `Exception` Aussi appelées Checked exceptions : des cas exceptionnels qui sont documentés et doivent être anticipés et gérés ### `RuntimeException` Aussi appelées Unchecked exceptions : peuvent arriver à l'intérieur de l'application. Indiquent généralement des erreurs de programmation ou des mauvaises utilisation des APIs. ## Exception handler : "attraper les exceptions" Se fait dans un bloc `try catch`. Ex. ouvrir un fichier est une opération « risquée ». Le fichier peut être absent. ```java try { // code risqué } catch (Exception e) { // traiter le problème proprement } // optionnel finally { // sera exécuté quoi qu'il arrive // aussi bien quand il y a une erreur // que quand tout se passe bien } ``` Ex. Que se passe-t-il si on essaye d'ouvrir de fichier ? ```java String texte = Files.readString(Path.of("text.txt")); ``` > [!example]- Pour gérer les problèmes potentiels > ```java > try { > String texte = Files.readString(Path.of("text.txt")); > System.out.println("Voici le contenu du fichier"); > System.out.println(texte); > } catch (IOException e) { > System.err.println("Le fichier n'a pas pu être ouvert. Cause : " + e ); > } > ``` ### Traiter plusieurs exceptions ```java try { URI uri = Objects.requireNonNull(resource).toURI(); String maressource = Files.readString(Path.of(uri)); System.out.println(maressource); } catch (IOException | URISyntaxException e) { System.err.println("Problème : "+e); } ``` ## Lever une exception : `throw` https://www.baeldung.com/java-common-exceptions ```java throw new IllegalArgumentException("Arg was not provided"); ``` ## Gérer des exceptions : try catch ### finally ### Try with resource ## Déclarer des exceptions personnalisées Les exceptions sont des classes et elles bénéficient des caractéristiques de celles-ci. On peut les hériter pour créer des hiérarchies d'exceptions. ## Documenter les exceptions Les exceptions, font partie du contrat d'une méthode. Si une exception est sensée arriver, elle devrait être documentée, même si c'est une exception unchecked. ## Antipatterns > [!danger] Antipattern : silent exception > [!danger] Antipattern : catch and log > [!warning] Opinion : utiliser les exceptions comme un else > [!danger] Antipattern : attraper et envelopper une exception sans y adjoindre la cause https://gaetanopiazzolla.github.io/java/exception/patterns/2024/07/01/java-exception-anti-patterns.html ## Pattern : Error codes #todo ## Pattern : séparer exceptions techniques et métier Distinguer les exceptions métier des exceptions techniques Il y a en gros 2 raisons pour lesquelles quelque choses pourrait mal se passer lors de l'exécution (runtime) - des **problèmes techniques** qui nous empêchent d'utiliser le programme - de la **logique métier** qui nous empêche **d'utiliser incorrectement** le programme Utiliser la même hiérarchie d'exception créer de la confusion entre les 2 situations. ### Problèmes techniques Un problème technique inattendu peut arriver du fait d'une erreur de programmation. Ex. essayer d'atteindre le 67ème élément d'un tableau qui n'en contient que 20. Dans le cas , le programme n'est pas dans un état normal et une exception devrait être levée. On ne devrait pas essayer de résoudre ces erreurs directement dans le code mais plutôt les faire remonter au plus haut du programme et laisser un mécanisme de gestion d'erreur général s'assurer que le système reste dans un état stable (ex. annuler les transactions de base de données, logger et alerter les opérations, retourner un message d'erreur lisible à l'utilisateur). ### Problèmes métier Il y a des fois où on ne peut pas continuer un traitement pour des raisons de logique métier. Il peut arriver qu'on considère ces cas comme exceptionnels. Une erreur inhabituelle, indésirable mais pas incorrecte programmatiquement. Par exemple, je souhaite retirer de l'argent d'un compte en banque qui n'a pas assez de fonds. Ce type de situations fait partie du contrat et lever une exception est un chemin de retour alternatif qui fait partie du modèle et l'appelant devrait être conscient et préparé à le gérer. Dans ces situations, il est approprié de créer une exception spécifique ou hiérarchie d'exceptions séparée pour permettre au client de gérer la situation selon ses propres termes. https://github.com/97-things/97-things-every-programmer-should-know/blob/master/en/thing_21/README.md ## Exceptions courantes en Java Les quelques exceptions natives que vous pourriez lever dans vos programmes - `IllegalArgumentException` : quand un argument incorrect est donné à une méthode ou constructeur - `UnsupportedOperationException` : quand vous n'avez pas encore implémenté une méthode ou si une opération n'est pas supportée dans une sous-classe - `IllegalStateException` : quand les données permettant de réaliser un traitement sont corrompues, incomplètes ou incohérentes ## À suivre [[IO en Java]] -->