‫Instructeur : Dans cette vidéo, parlons de quelque
‫chose que nous avons dans node. js appelé rejets non gérés,
‫puis apprenez comment nous pouvons réellement les gérer.
‫Ainsi, à ce stade, nous avons géré avec succès
‫les erreurs dans notre
‫application express en transmettant les erreurs asynchrones opérationnelles dans un
‫middleware global de gestion des erreurs.
‫Cela renvoie ensuite les messages d'erreur pertinents au client
‫en fonction du type d'erreur qui s'est produite, n'est-ce pas ?
‫Cependant, il peut également se produire des erreurs en dehors d'express et un
‫bon exemple de cela dans notre application actuelle est la connexion
‫à la base de données mongodb.
‫Alors imaginez que la base de données est en panne pour une raison quelconque
‫ou pour une raison quelconque, nous ne pouvons pas nous connecter.
‫Et dans ce cas, il y a aussi
‫des erreurs que nous devons gérer.
‫Mais ils ne se sont pas produits dans notre application express
‫et donc, bien sûr, notre gestionnaire d'erreurs que nous avons
‫implémenté ne détectera pas ces erreurs, n'est-ce pas ?
‫Et donc juste pour tester ce qui se passe,
‫allons-y et changeons notre mot de passe mongodb, d'accord ?
‫Parce que de cette façon, nous
‫ne pourrons pas nous connecter à la base de données, n'est-ce pas ?
‫Et donc nous devrions alors obtenir une sorte
‫d'erreur, et allons donc ici dans notre
‫fichier serveur et sauvegardons-le afin de recharger notre serveur,
‫augmentons-le ici, et en effet,
‫nous avons ici un rejet de promesse non géré.
‫Et c'est en fait le sujet de cette vidéo.
‫Ainsi, un rejet de promesse non géré signifie que quelque part dans notre
‫code, il y a une promesse qui a été rejetée.
‫Mais ce rejet n'a été traité nulle part, d'accord ?
‫Et ici, vous voyez également un avertissement de dépréciation qui indique
‫qu'à l'avenir, les rejets non gérés quitteront simplement
‫le programme de nœud en cours d'exécution, ce qui peut ne
‫pas toujours être ce que vous voulez, d'accord ?
‫Résolvons donc ce problème et débarrassons-nous
‫de ce rejet de promesse non géré.
‫Maintenant, dans cet exemple simple ici,
‫il serait en fait
‫assez facile de gérer ce rejet, n'est-ce pas ?
‫Tout ce que nous aurons à faire serait
‫de venir ici à ce morceau de code où notre connexion est réellement établie,
‫puis d'y ajouter un gestionnaire de capture, n'est-ce pas ?
‫Donc un peu comme ça, et puis
‫ici, nous pourrions gérer ce
‫rejet et n'obtiendrions plus cette erreur.
‫Permettez-moi de vous le montrer rapidement.
‫Alors réessayez.
‫Et maintenant, vous obtenez une erreur qui est bien sûr le résultat
‫de ce journal ici, mais bien
‫sûr, nous n'obtenons pas de rejet de promesse non géré,
‫encore une fois, parce que nous l'avons en fait géré ici, d'accord ?
‫Cela fonctionnerait, bien sûr, mais je veux vraiment vous montrer comment gérer
‫globalement les promesses rejetées non gérées, car dans une application
‫plus importante, il peut devenir un peu plus difficile
‫de toujours garder une trace de toutes les promesses qui pourraient
‫être rejetées à un moment donné. point, d'accord?
‫Et donc à un moment donné, vous
‫pourriez avoir un refus de promesse non géré quelque part
‫et laissez-moi donc vous montrer comment gérer cela globalement.
‫Et donc apprenons maintenant à gérer les rejets non gérés et
‫nous allons le faire ici.
‫Et rappelez-vous comment dans l'une des premières sections du
‫cours, nous avons parlé d'événements et
‫d'auditeurs d'événements, n'est-ce pas ?
‫Et maintenant, il est temps d'utiliser réellement ces connaissances.
‫Ainsi, chaque fois qu'il y a un
‫rejet non géré quelque part dans notre application, l'objet
‫de processus émettra un objet appelé rejet non géré
‫et nous pouvons donc nous abonner à cet événement comme ceci.
‫Donc processus. on, rappelez-vous, puis le
‫nom de l'événement, le rejet non géré, puis
‫la fonction de
‫rappel ici reçoit une erreur, et donc allons-y
‫et notons l'erreur sur la console.
‫Alors utilisons err. nom et erreur. un message.
‫Ce sont donc en quelque sorte des valeurs par défaut que
‫nous avons sur toutes les erreurs dans node. js, d'accord ?
‫D'accord, et après l'enregistrement, nous obtenons déjà ici
‫le nom de l'erreur ainsi que le message d'erreur.
‫Donc mauvaise authentification car, bien sûr, nous avons le mauvais
‫mot de passe.
‫Et donc en ce moment, le rejet de la promesse non
‫gérée est maintenant réellement géré.
‫Et bien sûr, pas seulement celui de cette connexion échouée,
‫mais tout autre rejet de promesse que nous pourrions
‫ne pas attraper quelque part dans l'application est traité ici dans cette
‫finale, appelons-le filet de sécurité, d'accord ?
‫Nous devons donc toujours supposer que nous, en tant que
‫programmeurs, allons faire des erreurs.
‫Et donc c'est toujours mieux d'avoir un endroit central comme celui-ci pour
‫gérer tous les refus de
‫promesse comme un dernier filet de sécurité, d'accord ?
‫Maintenant, si nous avons vraiment un problème avec
‫la connexion à la base de données, comme dans cet
‫exemple, alors notre application ne fonctionnera pas du tout.
‫Et donc tout ce que nous
‫pouvons vraiment faire ici est de fermer notre application, d'accord ?
‫Donc, pour arrêter l'application, nous utilisons process. sortir.
‫Et nous avons déjà utilisé cela auparavant
‫dans ce script où nous avons importé toutes les
‫données dans la base de données à partir du fichier JSON, vous vous souvenez ?
‫Donc processus. exit et puis
‫ici, nous pouvons réellement passer un code.
‫Et le code zéro représente un
‫succès et un représente une exception non capturée.
‫Et c'est donc celui qui est habituellement utilisé ici, d'accord ?
‫Donc généralement, vous le verrez toujours comme ça.
‫Et ajoutons juste comme un journal ici, console. log unhandler le
‫rejet, quelque chose
‫comme ça.
‫Alors vous voyez, j'aime beaucoup celui-ci, celui-ci ici.
‫Laissant juste ce nœud...
‫Pas vraiment utilisateur, mais
‫notre journal que nous fermons, d'accord ?
‫Et maintenant, vous voyez que l'application s'est réellement écrasée.
‫Et c'est à cause de ce processus. sors d'ici, d'accord ?
‫Maintenant, il y a juste un problème avec la
‫façon dont nous l'avons mis
‫en œuvre en ce moment et c'est que la façon dont
‫nous l'implémentons ici est donc juste. exit est une manière
‫très abrupte de terminer le programme car cela
‫annulera immédiatement toutes les requêtes en cours d'exécution ou en
‫attente et ce n'est donc peut-être pas une bonne idée, d'accord ?
‫Et donc généralement, ce que nous faisons, c'est arrêter gracieusement
‫là où nous fermons d'abord le serveur
‫et seulement ensuite, nous arrêtons l'application, d'accord ?
‫Alors allons...
‫Avant de faire cela, nous devons enregistrer
‫le serveur ici essentiellement dans une variable, d'accord ?
‫Et donc le résultat de l'appel de l'application. listen est un serveur et jusqu'à
‫présent, sur ce serveur, on peut alors dire serveur. close qui, comme son nom l'indique,
‫fermera le serveur, puis après cela,
‫il exécutera cette fonction
‫de rappel que nous lui avons transmise et ce n'est
‫donc qu'ici,
‫où nous arrêtons ensuite le serveur, d'accord ?
‫Et donc en faisant cela, en faisant server. close, nous donnons
‫au serveur le temps de terminer toutes les demandes encore
‫en attente ou en cours de traitement à ce moment-là,
‫et seulement après cela, le serveur est
‫alors pratiquement tué, d'accord ?
‫Donc, quand nous lui donnons
‫un coffre-fort, il n'aura pas exactement la même
‫apparence parce que, (rires) ouais, nous sommes comme les seuls
‫qui accèdent vraiment à cette application mais dans le scénario du
‫monde réel, nous devrions toujours le faire comme ça, d'accord ?
‫Et bien sûr, ce n'est pas
‫vraiment idéal que l'application plante, non ?
‫Parce qu'en ce moment, bien sûr, l'application ne fonctionne pas, elle
‫ne fonctionne pas du tout, n'est-ce pas ?
‫Et donc généralement, dans une application de production sur un serveur Web, nous
‫aurons généralement un outil en place qui
‫redémarre l'application juste après son crash, ou également certaines des plates-formes
‫qui hébergent le nœud. js le
‫fera automatiquement tout seul, d'accord ?
‫Parce que, bien sûr, nous ne voulons pas laisser l'application
‫suspendue comme ça pour toujours.
‫Donc ce n'est pas utile non plus, d'accord ?
‫Et donc, fondamentalement, c'est ainsi que
‫vous gérez les promesses rejetées non gérées.
‫Donc, encore une fois, en gros, nous écoutons
‫cet événement de rejet non géré, ce qui nous
‫permet ensuite de gérer toutes
‫les erreurs qui se produisent dans le
‫code asynchrone qui n'étaient pas gérées auparavant.
‫Mais maintenant, vous pourriez demander, qu'en est-il du code synchrone ?
‫Où allons-nous gérer ça?
‫Et la réponse à cela se trouve, comme vous pouvez
‫l'imaginer, dans la vidéo suivante.