Hiérarchie des exceptions, erreurs

« Salut Amigo ! »

« Salut, Ellie ! Comment va la vie ?

« Excellent, merci. Comment allez-vous ? »

"Génial, ce matin des tonnes de nouvelles choses m'ont été expliquées."

"Eh bien, c'est super. Tu n'es pas fatigué ?"

« Ouais, il y a ça. Je suis un peu fatigué.

"Alors tu as juste eu de la chance. Je voulais couvrir un sujet vaste et complexe aujourd'hui, mais à la dernière minute, j'ai changé d'avis et j'ai décidé de couvrir un petit sujet facile."

« Petit et facile ? Je suis prêt.

"Aujourd'hui, nous examinerons en détail le sujet des exceptions ."

« Parlez-vous de la gestion des erreurs ? »

"Vous ne devez pas considérer les exceptions comme des erreurs. Les exceptions ressemblent davantage à des rapports indiquant que" quelque chose d'inattendu s'est produit ". Sur la base de ces rapports, vous pouvez proposer des actions alternatives."

"Tout est une question de méthodes.  Lorsque vous appelez une méthode, elle promet de faire ce pour quoi elle a été appelée. "

"Quand une méthode, pour une raison quelconque, ne peut pas faire ce pour quoi elle a été appelée, elle doit le faire savoir à l'appelant."

"En d'autres termes, la pire chose qui puisse arriver est qu'une méthode ne fasse pas son travail et n'en parle à personne. Rien ne pourrait être pire que cela. Vous perdez le contrôle de la situation lorsque cela se produit. "

"Lorsque vous êtes un nouveau programmeur, il semble que vous appelez simplement des méthodes et qu'elles sont sûres de faire ce que vous leur avez demandé de faire."

"Lorsque vous êtes un programmeur expérimenté, vous savez qu'il peut y avoir des dizaines de facteurs qui affectent la capacité d'une méthode à faire son travail, et qu'il existe de nombreux cas qui pourraient empêcher une méthode de terminer son travail."

"Du point de vue du programmeur, il est mille fois mieux qu'un programme se termine lorsqu'il rencontre une erreur que si le programme rencontre une erreur puis continue à fonctionner (incorrectement) sans que l'utilisateur ne se rende compte de ce qui s'est passé."

"Donc, le programme montrant quelque chose de mal pourrait être pire que s'il se fermait et perdait toutes les données?"

"Qu'est-ce qui vous a fait penser que le programme affiche simplement quelque chose de manière incorrecte ? Peut-être que le programme contient de nombreux bogues et que toutes vos données seront irrémédiablement perdues ? Supposons que vous ayez tapé du texte pendant 3 heures, mais rien ne sera enregistré car un erreur qui s'est produite après seulement deux minutes."

"Quand un programmeur novice rencontre des exceptions, il est frustré."

"Mais en réalité, les exceptions révèlent tous les scénarios possibles qu'il aurait dû prévoir mais ne l'a pas fait."

"Vous pourriez choisir de ne pas gérer les exceptions et cela ferait de vous un mauvais programmeur. Mais si vos méthodes ne génèrent pas d'exceptions, alors vous n'êtes pas du tout programmeur - parce que vous n'avez pas compris cette simple vérité :"

"une méthode fait ce pour quoi elle a été écrite, ou elle lève une exception. Il n'y a pas de troisième option !"

"D'accord, je te crois. Je promets d'utiliser des exceptions."

"Génial. Alors laissez-moi vous parler de la hiérarchie des exceptions :"

"La hiérarchie des exceptions est basée sur quatre classes."

"La classe de base la plus basse est Throwable ."

"Les classes Error et Exception en héritent."

" L'exception d'exécution hérite de l'exception ."

"La classe Error est la classe de base pour les erreurs JVM telles que StackOverFlow , OutOfMemory , …"

"Un programme ne peut généralement pas récupérer de telles erreurs, ce qui le conduit à se terminer."

"En effet, que faire s'il n'y a pas assez de mémoire pour que le programme continue à fonctionner normalement ou s'il y a eu un débordement de pile ?"

" Exception est la classe de base pour toutes les exceptions ordinaires lancées par un programme.  RuntimeException est un type spécial d' exception qui a des règles légèrement différentes."

"Que sont-ils?"

"C'est exactement ce que je vais expliquer maintenant."

"Comme vous vous en souvenez probablement, les exceptions se divisent en deux catégories : cochées et non cochées ."

"Si une méthode lève des exceptions vérifiées , alors la méthode qui l'appelle doit envelopper l'appel dans un bloc try-catch . Eh bien, soit cela, soit relancé l'exception (à son appelant) en indiquant clairement les levées dans la signature de la méthode."

"Ces règles/restrictions ne s'appliquent pas aux exceptions non contrôlées."

"Ainsi, toutes les exceptions qui héritent d'Exception sont considérées comme cochées. À l'exception des exceptions qui héritent de RuntimeException, qui sont considérées comme non cochées."

"Uh-huh. Je me souviens que tu m'avais dit quelque chose comme ça plus tôt."

"Amigo ! Ils posent des questions sur la hiérarchie des exceptions dans chaque entretien . Je le répète, à chaque entretien . Vous devez parfaitement connaître ce sujet."

"OK. Je vais tout relire et comprendre. Merci de m'avoir aidé, Ellie."