Exceptions : cochées, décochées et personnalisées

Salut! Dans la dernière leçon, nous nous sommes familiarisés avec les exceptions dans le langage Java et avons vu des exemples sur la façon de les utiliser. Aujourd'hui, nous allons approfondir la structure des exceptions et apprendre à écrire nos propres exceptions :)

Types d'exceptions

Comme nous l'avons dit précédemment, il y a beaucoup d'exceptions en Java, presque 400 ! Mais ils sont tous divisés en groupes, il est donc assez facile de s'en souvenir. Voici à quoi cela ressemble : toutes les exceptions ont un ancêtre commun dans la Throwableclasse. Deux grands groupes en sont dérivés : les exceptions ( Exception ) et les erreurs ( Error ). Erreur - Cela représente une erreur d'exécution critique liée au fonctionnement de la machine virtuelle Java. Dans la plupart des cas, Error n'a pas besoin d'être traité, car il indique de graves défauts dans le code. Les plus célèbres d'entre elles sont StackOverflowError (cela se produit, par exemple, lorsqu'une méthode s'appelle sans fin) et OutOfMemoryError(cela se produit lorsqu'il n'y a pas assez de mémoire pour créer de nouveaux objets). Comme vous pouvez le constater, dans ces situations, il n'y a généralement absolument rien à gérer au moment de l'exécution : le code est simplement écrit de manière incorrecte et doit être retravaillé. Exception - Cela représente, eh bien, une exception : une situation exceptionnelle et imprévue qui se produit pendant l'exécution du programme. Ils ne sont pas aussi graves que Error, mais ils nécessitent tout de même notre attention. Toutes les exceptions sont divisées en 2 types : cochées et non cochées . Toutes les exceptions vérifiées sont dérivées de la Exceptionclasse. Que signifie "vérifié" ? Nous y avons fait allusion dans la dernière leçon : "Le compilateur Java connaît donc les exceptions les plus courantes et les situations dans lesquelles elles peuvent se produire." Par exemple, il sait que si le code lit les données d'un fichier, le fichier pourrait facilement ne pas exister. Et il y a beaucoup de telles situations (ce qu'il peut déduire). En conséquence, le compilateur vérifie à l'avance dans notre code la présence de ces exceptions potentielles. S'il les trouve, il ne compilera pas le code tant que nous ne les aurons pas manipulés ou que nous ne les aurons pas renvoyés. Le deuxième type d'exception est "non contrôlé". Ils sont dérivés de la RuntimeExceptionclasse. En quoi sont-elles différentes des exceptions vérifiées ? Il semble qu'il existe également de nombreuses classes différentes dérivées deRuntimeException(qui décrivent les exceptions d'exécution). La différence est que le compilateur n'anticipe pas ces erreurs. Il semble dire : "Lorsque le code a été écrit, je n'ai rien trouvé de suspect, mais quelque chose s'est mal passé pendant son exécution. Apparemment, il y a des erreurs dans le code !" Et en effet c'est vrai. Les exceptions non vérifiées sont le plus souvent le résultat d'erreurs du programmeur. Et le compilateur ne peut évidemment pas prévoir toutes les mauvaises situations possibles que les gens pourraient créer de leurs propres mains. :) Par conséquent, il ne vérifie pas si de telles exceptions sont gérées dans notre code. Vous avez déjà rencontré plusieurs exceptions non contrôlées :

• Une ArithmeticException se produit lors de la division par zéro
• Une ArrayIndexOutOfBoundsException se produit lorsque vous essayez d'accéder à une position en dehors du tableau.

Bien sûr, vous pouvez imaginer que les créateurs de Java auraient pu introduire une gestion obligatoire des exceptions, mais dans ce cas, le code serait trop compliqué. Pour toute opération de division, devriez-vous écrire un try-catchbloc pour vérifier si vous avez accidentellement divisé par zéro ? Chaque fois que vous accédiez à un tableau, vous deviez écrire un try-catchbloc pour vérifier si votre index était hors limites. Tout serait en code spaghetti et serait complètement illisible. Il est logique que cette idée ait été abandonnée. Par conséquent, les exceptions non contrôlées n'ont pas besoin d'être gérées dans try-catchdes blocs ou relancées (bien que cela soit techniquement possible, comme avec Error).

Comment lever votre propre exception

Bien sûr, les créateurs de Java ne peuvent pas prévoir toutes les situations exceptionnelles qui pourraient survenir dans les programmes. Il y a trop de programmes dans le monde, et ils sont trop diversifiés. Mais il n'y a pas lieu de s'inquiéter, car vous pouvez créer votre propre exception, si nécessaire. C'est très facile à faire. Il ne vous reste plus qu'à créer votre propre classe. Vous devez vous assurer que son nom se termine par "Exception". Le compilateur ne l'exige pas, mais les autres programmeurs lisant votre code comprendront immédiatement qu'il s'agit d'une classe d'exception. De plus, indiquez que la classe est héritée de la Exceptionclasse (le compilateur l'exige). Par exemple, supposons que nous ayons une Dogclasse. Nous pouvons promener le chien en utilisant lewalk()méthode. Mais avant cela, nous devons vérifier si notre animal porte un collier, une laisse et une muselière. Si l'un de ces équipements est manquant, nous lançons notre propre exception : DogIsNotReadyException . Son code ressemble à ceci :

public class DogIsNotReadyException extends Exception {

   public DogIsNotReadyException(String message) {
       super(message);
   }
}

Pour indiquer que la classe est une exception, vous devez écrire « extend Exception » après le nom de la classe (cela signifie « la classe est dérivée de la classe Exception »). Dans le constructeur, nous appelons simplement le Exceptionconstructeur de classe avec le message String (si l'exception se produit, nous afficherons le message, une description de l'erreur, à l'utilisateur). Voici à quoi cela ressemble dans notre code de classe :

public class Dog {

   String name;
   boolean isCollarPutOn;
   boolean isLeashPutOn;
   boolean isMuzzlePutOn;


   public Dog(String name) {
       this.name = name;
   }

   public static void main(String[] args) {

   }

   public void putCollar() {

       System.out.println("The collar is on!");
       this.isCollarPutOn = true;
   }

   public void putLeash() {

       System.out.println("The leash is on!");
       this.isLeashPutOn = true;
   }

   public void putMuzzle() {
       System.out.println("The muzzle is on!");
       this.isMuzzlePutOn = true;
   }

   public void walk() throws DogIsNotReadyException {

   System.out.println("We're getting ready for a walk!");
   if (isCollarPutOn && isLeashPutOn && isMuzzlePutOn) {
       System.out.println("Hooray, let's go for a walk! " + name + " is very happy!");
   } else {
       throw new DogIsNotReadyException(name + " is not ready for a walk! Check the gear!");
   }
 }

}

Maintenant, notre walk()méthode lève une DogIsNotReadyException . Cela se fait avec le mot clé throw. Comme nous l'avons dit précédemment, une exception est un objet. Ainsi, lorsqu'une exception se produit (il manque quelque chose au chien) dans notre méthode, nous créons un nouvel DogIsNotReadyExceptionobjet et le lançons à l'aide du mot-clé throw. Nous ajoutons " throws DogIsNotReadyException " à la déclaration de la méthode. En d'autres termes, maintenant le compilateur est conscient que l'appel de la walk()méthode pourrait se transformer en une situation exceptionnelle. Par conséquent, cette exception doit être gérée si nous appelons cette méthode quelque part dans notre programme. Essayons de faire cela dans la main()méthode :

public static void main(String[] args) {
  
   Dog dog = new Dog("Buddy");
   dog.putCollar();
   dog.putMuzzle();
   dog.walk();// Unhandled exception: DogIsNotReadyException
}

Cela ne compilera pas. L'exception n'est pas gérée ! Nous encapsulons notre code dans un try-catchbloc pour gérer l'exception :

public static void main(String[] args) {

   Dog dog = new Dog("Buddy");
   dog.putCollar();
   dog.putMuzzle();
   try {
       dog.walk();
   } catch (DogIsNotReadyException e) {
       System.out.println(e.getMessage());
       System.out.println("Checking the gear! Is the collar on? " + dog.isCollarPutOn + "\r\n Is the leash on? "
       + dog.isLeashPutOn + "\r\n Is the muzzle on? " + dog.isMuzzlePutOn);
   }
}

Regardons maintenant la sortie de la console : Le collier est allumé ! La muselière est allumée ! On se prépare pour une balade ! Buddy n'est pas prêt pour une promenade ! Vérifiez l'équipement! Vérification de l'équipement ! Le collier est-il en place ? true La laisse est-elle en place ? false La muselière est-elle allumée ? true Regardez à quel point la sortie de la console était plus informative ! Nous voyons chaque étape franchie dans le programme; nous voyons où l'erreur s'est produite et nous pouvons également voir immédiatement ce qui manque à notre chien. :) Et c'est ainsi que vous créez vos propres exceptions. Comme vous pouvez le voir, il n'y a rien de compliqué à ce sujet. Et même si les créateurs de Java n'ont pas pris la peine d'inclure dans le langage une exception spéciale pour les chiens mal équipés, nous avons corrigé leur oubli. :)