‫Instructeur : D'accord !
‫Et maintenant, pour terminer cette
‫section, apprenons à intercepter les exceptions non interceptées.
‫Mais que sont exactement les exceptions non capturées ?
‫Eh bien, toutes les erreurs, ou appelons-les aussi bogues, qui se
‫produisent dans notre code synchrone
‫mais qui ne sont gérées nulle part sont appelées exceptions non interceptées.
‫Et comme avant, tout comme pour les rejets non gérés, nous avons
‫également un moyen de gérer les exceptions non interceptées.
‫Permettez-moi donc de vous montrer
‫rapidement un exemple d'exception non détectée.
‫Imaginons donc simplement que nous essayons
‫de consoler. enregistrer quelque chose qui n'existe pas.
‫Et donc tout de suite, nous obtenons cette erreur ici, x n'est pas défini,
‫puis par défaut, nous obtenons ici toute cette trace de
‫pile imprimée sur la console.
‫D'accord.
‫Et maintenant, pour résoudre ce problème, c'est très similaire à faire les
‫rejets non gérés.
‫Encore une fois, nous écoutons un événement,
‫cette fois il s'appelle uncaughtException.
‫Et bien sûr, il doit être entre guillemets.
‫Et puis comme avant, nous passons notre fonction de rappel.
‫D'accord.
‫Et maintenant, en fait, ce que nous faisons ici est très similaire à
‫ce que nous avons fait ici.
‫Nous voulons donc verrouiller l'erreur sur la
‫console afin qu'elle apparaisse ensuite dans les journaux de notre serveur, d'accord ?
‫Donc, nous donner un moyen de résoudre le problème.
‫Et puis nous voulons arrêter gracieusement le serveur.
‫Alors, en fait, je veux
‫imprimer toute l'erreur sur la console, et
‫pas seulement le message, d'accord ?
‫Et modifions aussi l'ordre ici,
‫mais c'est tout.
‫Donc pour le reste c'est pareil.
‫Et
‫ici, c'est bien sûr INSCRIVEZ-VOUS D'EXCEPTION !
‫Maintenant, je pourrais refactoriser ceci ici dans une fonction
‫agréable, mais gardons-le comme ça, d'accord ?
‫D'accord, alors réexécutons maintenant ceci.
‫Et donc jetons un coup d'œil à ce que nous avons ici.
‫Et en effet, nous voyons maintenant l'EXCEPTION IMPOSSIBLE !
‫Éteindre.
‫D'accord?
‫Et en fait, cela imprime à nouveau toute la pile sur
‫la console, mais je ne le veux pas vraiment.
‫Je n'aime pas ça.
‫Alors revenons en fait à ce que nous avions ici.
‫Alors errez. nom et puis erreur. un message.
‫D'accord, et maintenant nous
‫avons la ReferenceError que x n'est pas défini, d'accord ?
‫Et mettons simplement la même chose ici.
‫Alors comme avant.
‫D'accord.
‫Et c'est en fait tout
‫ce qu'il y a à attraper les exceptions non capturées.
‫Maintenant, alors qu'ici dans le rejet non géré,
‫le plantage de l'application comme nous l'avons fait ici
‫est facultatif, lorsqu'il y a une exception
‫non interceptée, nous devons vraiment, vraiment planter notre application car après
‫qu'il y ait eu une exception non interceptée, l'ensemble
‫du processus de nœud
‫est dans un -appelé état impur, d'accord ?
‫Et donc pour résoudre ce problème, le processus doit se
‫terminer puis être redémarré, d'accord ?
‫Et encore, en
‫production, nous devrions alors avoir un
‫outil en place qui redémarrera l'application après un crash.
‫Et de nombreux services d'hébergement le font
‫déjà, d'accord ?
‫Donc, complètement automatiquement sans que nous ayons à
‫faire quoi que ce soit.
‫Maintenant, dans Node. js, ce n'est pas
‫vraiment une bonne pratique de se fier aveuglément à ces deux gestionnaires
‫d'erreurs que nous venons d'implémenter ici, d'accord ?
‫Donc, idéalement, les erreurs devraient vraiment être traitées
‫là où elles se produisent.
‫Ainsi, par exemple, dans le problème de connexion à la base de données, nous
‫devrions bien sûr y ajouter un gestionnaire de capture
‫et ne pas simplement nous
‫fier au rappel de rejet non géré que nous avons ici, d'accord ?
‫Et certaines personnes disent même que nous ne devrions pas les utiliser du tout, mais je ne
‫suis pas d'accord avec cela.
‫Je pense qu'en tant que filet de sécurité, disons,
‫ils peuvent être très utiles et jouer un rôle dans notre application.
‫En fait, ce gestionnaire
‫ici devrait être tout en haut de notre code, d'accord ?
‫Ou du moins avant que tout autre code ne soit réellement exécuté.
‫Parce que regardez ce qui se passe si je déplace cette ligne de
‫code ici avant ce gestionnaire.
‫Donc, si je le mets ici, par
‫exemple, puis que je le sauve,
‫alors vous voyez en
‫fait que notre gestionnaire n'attrape pas cette exception, donc cette erreur ici, n'est-ce pas ?
‫Et c'est parce que ce n'est qu'ici à
‫la fin que nous commençons à écouter une exception non capturée.
‫Mais dans ce cas ici, l'exception non capturée
‫se produit avant même que nous écoutions cet événement.
‫Et donc par conséquent, nous n'avons aucun moyen de l'attraper, n'est-ce pas ?
‫Et donc idéalement, nous devrions le mettre ici, tout en haut, à nouveau avant
‫que tout autre code ne s'exécute.
‫Surtout celui de notre application.
‫Alors mettons-le en fait ici.
‫Maintenant, le problème ici
‫sera que le serveur n'est pas défini à ce stade.
‫Mais ce n'est pas
‫un problème, car en fait, nous n'avons pas
‫du tout besoin du serveur ici, d'accord ?
‫Et c'est parce que
‫ces erreurs, donc ces exceptions non
‫détectées, ne se produiront pas de manière asynchrone.
‫Donc, ils n'auront rien à
‫voir avec le serveur en fait.
‫Nous n'avons donc pas du tout besoin de ça ici.
‫Nous pouvons simplement l'enregistrer ici,
‫et nous l'avons maintenant avant d'avoir réellement besoin de
‫notre application principale.
‫Et donc si nous avons maintenant
‫une erreur, essayons d'abord ici, donc
‫vous voyez que maintenant
‫nous sommes de nouveau à l'attraper dans notre gestionnaire d'erreurs.
‫Mais si nous avions maintenant ce code, par exemple dans app. js, disons que cela n'a
‫pas vraiment d'importance, disons simplement que c'est ici, et
‫si nous l'exécutons
‫maintenant, alors vous voyez que nous attrapons
‫toujours cette exception dans notre
‫gestionnaire d'erreurs, ce qui n'était pas le cas auparavant.
‫D'accord?
‫Et maintenant juste pour
‫une expérience, que pensez-vous si nous mettons ce
‫code ici dans cette fonction middleware ?
‫À votre avis, que va-t-il se
‫passer lorsque nous enregistrerons ce fichier maintenant ?
‫Donc x n'est toujours défini nulle part, mais regardons
‫ce qui se passe lorsque nous
‫exécutons maintenant ce code.
‫Et maintenant, nous n'avons en fait aucune erreur.
‫Ou en fait, nous le
‫faisons, mais c'est uniquement à cause de notre rejet non géré,
‫qui est dû au fait que notre
‫mot de passe ici est toujours faux.
‫Donc, si nous sauvegardons cela et maintenant le sauvegardons à nouveau,
‫vous ne devriez voir aucune erreur du tout.
‫Et en effet, nous ne le faisons pas.
‫Et pourquoi est-ce que?
‫Eh bien, c'est parce que cette fonction middleware ici bien sûr
‫n'est appelée que dès
‫qu'il y a réellement une demande, n'est-ce pas ?
‫Et voyons donc ce qui se passe lorsque nous faisons une requête.
‫Et alors faisons une demande Get All Tours.
‫Et attendons-le.
‫Et, ici, nous obtenons un "Quelque chose s'est très mal passé ! " message d'erreur
‫avec le 500, et c'est aussi
‫parce qu'on est toujours
‫en mode production, d'accord ?
‫Mais de toute façon, recevoir ce message ici, rappelez-vous, signifie
‫que nous avons une erreur non opérationnelle ici.
‫Donc en gros une erreur que nous n'avons pas créée nous-mêmes.
‫Et donc, c'est ça, nous entrons maintenant
‫ici dans notre errorController, nous allons ici, n'est-ce pas ?
‫Donc, dans cette branche else ici dans la fonction sendErrorProd.
‫Et en fait, vous
‫voyez également l'erreur ici dans la console, d'accord ?
‫Et c'est ce qui se passe lorsqu'il
‫y a une erreur à l'intérieur d'un middleware Express, n'est-ce pas ?
‫Donc, Express, en cas d'erreur,
‫ira automatiquement au middleware de gestion des erreurs avec
‫cette erreur, d'accord ?
‫Et c'est pourquoi, lorsque
‫nous obtenons une erreur ici dans
‫l'une de nos fonctions middleware, elle ira immédiatement ici dans ce gestionnaire, d'accord ?
‫Et comme on
‫est en production, ça va entrer
‫ce bloc ici, mais comme ce n'est
‫pas une CastError, et pas cette erreur, et
‫pas une ValidationError, alors dès que l'erreur est effectivement envoyée,
‫ici même, on entre alors dans ce bloc .
‫Et encore une fois, c'est pourquoi nous envoyons cette erreur générique, d'accord ?
‫Quittons maintenant ce mode ici et
‫revenons à notre démarrage normal de npm.
‫Et donc maintenant, notre erreur sera envoyée comme ça, n'est-ce pas ?
‫Donc, envoyer une erreur de développement nous donnera tous les
‫détails sur l'erreur qui se produit.
‫Et maintenant, en effet, nous obtenons ReferenceError : x n'est pas défini.
‫D'accord?
‫Donc dans l'appli. js, ligne 21.
‫Et donc, la ligne 21 est là où elle se trouve,
‫mais débarrassons-nous en.
‫Je voulais juste te le montrer.
‫D'accord?
‫Quoi qu'il en soit, avec cela, nous fermons en fait
‫notre section de gestion des erreurs.
‫Et il pourrait y avoir un cours complet sur la
‫gestion des erreurs avec Node et Express, car c'est
‫vraiment un sujet incroyablement complexe.
‫Mais, dans cette section, vous apprenez les éléments
‫essentiels que vous devez connaître pour vraiment
‫commencer à créer des applications étonnantes.