1 00:00:01,120 --> 00:00:03,120 ‫Instructeur : Dans cette vidéo, parlons de quelque 2 00:00:03,120 --> 00:00:06,770 ‫chose que nous avons dans node. js appelé rejets non gérés, 3 00:00:06,770 --> 00:00:09,543 ‫puis apprenez comment nous pouvons réellement les gérer. 4 00:00:10,970 --> 00:00:14,400 ‫Ainsi, à ce stade, nous avons géré avec succès 5 00:00:14,400 --> 00:00:16,330 ‫les erreurs dans notre 6 00:00:16,330 --> 00:00:19,970 ‫application express en transmettant les erreurs asynchrones opérationnelles dans un 7 00:00:19,970 --> 00:00:22,410 ‫middleware global de gestion des erreurs. 8 00:00:22,410 --> 00:00:26,200 ‫Cela renvoie ensuite les messages d'erreur pertinents au client 9 00:00:26,200 --> 00:00:30,510 ‫en fonction du type d'erreur qui s'est produite, n'est-ce pas ? 10 00:00:30,510 --> 00:00:34,730 ‫Cependant, il peut également se produire des erreurs en dehors d'express et un 11 00:00:34,730 --> 00:00:38,520 ‫bon exemple de cela dans notre application actuelle est la connexion 12 00:00:38,520 --> 00:00:40,810 ‫à la base de données mongodb. 13 00:00:40,810 --> 00:00:43,700 ‫Alors imaginez que la base de données est en panne pour une raison quelconque 14 00:00:43,700 --> 00:00:46,000 ‫ou pour une raison quelconque, nous ne pouvons pas nous connecter. 15 00:00:46,000 --> 00:00:47,920 ‫Et dans ce cas, il y a aussi 16 00:00:47,920 --> 00:00:49,610 ‫des erreurs que nous devons gérer. 17 00:00:49,610 --> 00:00:52,800 ‫Mais ils ne se sont pas produits dans notre application express 18 00:00:52,800 --> 00:00:55,810 ‫et donc, bien sûr, notre gestionnaire d'erreurs que nous avons 19 00:00:55,810 --> 00:00:58,560 ‫implémenté ne détectera pas ces erreurs, n'est-ce pas ? 20 00:00:58,560 --> 00:01:01,790 ‫Et donc juste pour tester ce qui se passe, 21 00:01:01,790 --> 00:01:05,110 ‫allons-y et changeons notre mot de passe mongodb, d'accord ? 22 00:01:05,110 --> 00:01:06,960 ‫Parce que de cette façon, nous 23 00:01:06,960 --> 00:01:10,180 ‫ne pourrons pas nous connecter à la base de données, n'est-ce pas ? 24 00:01:10,180 --> 00:01:13,110 ‫Et donc nous devrions alors obtenir une sorte 25 00:01:13,110 --> 00:01:15,510 ‫d'erreur, et allons donc ici dans notre 26 00:01:15,510 --> 00:01:18,633 ‫fichier serveur et sauvegardons-le afin de recharger notre serveur, 27 00:01:20,710 --> 00:01:23,040 ‫augmentons-le ici, et en effet, 28 00:01:23,040 --> 00:01:26,120 ‫nous avons ici un rejet de promesse non géré. 29 00:01:26,120 --> 00:01:29,510 ‫Et c'est en fait le sujet de cette vidéo. 30 00:01:29,510 --> 00:01:33,600 ‫Ainsi, un rejet de promesse non géré signifie que quelque part dans notre 31 00:01:33,600 --> 00:01:37,140 ‫code, il y a une promesse qui a été rejetée. 32 00:01:37,140 --> 00:01:41,270 ‫Mais ce rejet n'a été traité nulle part, d'accord ? 33 00:01:41,270 --> 00:01:44,920 ‫Et ici, vous voyez également un avertissement de dépréciation qui indique 34 00:01:44,920 --> 00:01:48,008 ‫qu'à l'avenir, les rejets non gérés quitteront simplement 35 00:01:48,008 --> 00:01:51,710 ‫le programme de nœud en cours d'exécution, ce qui peut ne 36 00:01:51,710 --> 00:01:54,940 ‫pas toujours être ce que vous voulez, d'accord ? 37 00:01:54,940 --> 00:01:57,450 ‫Résolvons donc ce problème et débarrassons-nous 38 00:01:57,450 --> 00:02:00,000 ‫de ce rejet de promesse non géré. 39 00:02:00,000 --> 00:02:01,910 ‫Maintenant, dans cet exemple simple ici, 40 00:02:01,910 --> 00:02:03,270 ‫il serait en fait 41 00:02:03,270 --> 00:02:05,770 ‫assez facile de gérer ce rejet, n'est-ce pas ? 42 00:02:05,770 --> 00:02:08,060 ‫Tout ce que nous aurons à faire serait 43 00:02:08,060 --> 00:02:11,550 ‫de venir ici à ce morceau de code où notre connexion est réellement établie, 44 00:02:11,550 --> 00:02:14,100 ‫puis d'y ajouter un gestionnaire de capture, n'est-ce pas ? 45 00:02:14,100 --> 00:02:16,580 ‫Donc un peu comme ça, et puis 46 00:02:16,580 --> 00:02:18,640 ‫ici, nous pourrions gérer ce 47 00:02:18,640 --> 00:02:20,970 ‫rejet et n'obtiendrions plus cette erreur. 48 00:02:20,970 --> 00:02:22,820 ‫Permettez-moi de vous le montrer rapidement. 49 00:02:29,905 --> 00:02:31,960 ‫Alors réessayez. 50 00:02:31,960 --> 00:02:35,630 ‫Et maintenant, vous obtenez une erreur qui est bien sûr le résultat 51 00:02:35,630 --> 00:02:37,950 ‫de ce journal ici, mais bien 52 00:02:37,950 --> 00:02:41,010 ‫sûr, nous n'obtenons pas de rejet de promesse non géré, 53 00:02:41,010 --> 00:02:45,060 ‫encore une fois, parce que nous l'avons en fait géré ici, d'accord ? 54 00:02:45,060 --> 00:02:48,580 ‫Cela fonctionnerait, bien sûr, mais je veux vraiment vous montrer comment gérer 55 00:02:48,580 --> 00:02:51,720 ‫globalement les promesses rejetées non gérées, car dans une application 56 00:02:51,720 --> 00:02:54,680 ‫plus importante, il peut devenir un peu plus difficile 57 00:02:54,680 --> 00:02:57,860 ‫de toujours garder une trace de toutes les promesses qui pourraient 58 00:02:57,860 --> 00:03:00,590 ‫être rejetées à un moment donné. point, d'accord? 59 00:03:00,590 --> 00:03:03,280 ‫Et donc à un moment donné, vous 60 00:03:03,280 --> 00:03:06,690 ‫pourriez avoir un refus de promesse non géré quelque part 61 00:03:06,690 --> 00:03:09,860 ‫et laissez-moi donc vous montrer comment gérer cela globalement. 62 00:03:09,860 --> 00:03:14,070 ‫Et donc apprenons maintenant à gérer les rejets non gérés et 63 00:03:14,070 --> 00:03:16,160 ‫nous allons le faire ici. 64 00:03:16,160 --> 00:03:19,530 ‫Et rappelez-vous comment dans l'une des premières sections du 65 00:03:19,530 --> 00:03:21,900 ‫cours, nous avons parlé d'événements et 66 00:03:21,900 --> 00:03:24,080 ‫d'auditeurs d'événements, n'est-ce pas ? 67 00:03:24,080 --> 00:03:28,010 ‫Et maintenant, il est temps d'utiliser réellement ces connaissances. 68 00:03:28,010 --> 00:03:30,940 ‫Ainsi, chaque fois qu'il y a un 69 00:03:30,940 --> 00:03:34,180 ‫rejet non géré quelque part dans notre application, l'objet 70 00:03:34,180 --> 00:03:37,470 ‫de processus émettra un objet appelé rejet non géré 71 00:03:37,470 --> 00:03:41,223 ‫et nous pouvons donc nous abonner à cet événement comme ceci. 72 00:03:42,250 --> 00:03:46,903 ‫Donc processus. on, rappelez-vous, puis le 73 00:03:48,004 --> 00:03:52,053 ‫nom de l'événement, le rejet non géré, puis 74 00:03:52,930 --> 00:03:55,240 ‫la fonction de 75 00:03:55,240 --> 00:03:59,369 ‫rappel ici reçoit une erreur, et donc allons-y 76 00:03:59,369 --> 00:04:02,793 ‫et notons l'erreur sur la console. 77 00:04:03,780 --> 00:04:08,653 ‫Alors utilisons err. nom et erreur. un message. 78 00:04:09,620 --> 00:04:11,640 ‫Ce sont donc en quelque sorte des valeurs par défaut que 79 00:04:12,500 --> 00:04:16,073 ‫nous avons sur toutes les erreurs dans node. js, d'accord ? 80 00:04:17,570 --> 00:04:20,930 ‫D'accord, et après l'enregistrement, nous obtenons déjà ici 81 00:04:20,930 --> 00:04:24,410 ‫le nom de l'erreur ainsi que le message d'erreur. 82 00:04:24,410 --> 00:04:27,940 ‫Donc mauvaise authentification car, bien sûr, nous avons le mauvais 83 00:04:27,940 --> 00:04:29,490 ‫mot de passe. 84 00:04:29,490 --> 00:04:32,360 ‫Et donc en ce moment, le rejet de la promesse non 85 00:04:32,360 --> 00:04:33,960 ‫gérée est maintenant réellement géré. 86 00:04:33,960 --> 00:04:37,430 ‫Et bien sûr, pas seulement celui de cette connexion échouée, 87 00:04:37,430 --> 00:04:40,410 ‫mais tout autre rejet de promesse que nous pourrions 88 00:04:40,410 --> 00:04:44,260 ‫ne pas attraper quelque part dans l'application est traité ici dans cette 89 00:04:44,260 --> 00:04:46,880 ‫finale, appelons-le filet de sécurité, d'accord ? 90 00:04:46,880 --> 00:04:49,890 ‫Nous devons donc toujours supposer que nous, en tant que 91 00:04:49,890 --> 00:04:51,410 ‫programmeurs, allons faire des erreurs. 92 00:04:51,410 --> 00:04:54,740 ‫Et donc c'est toujours mieux d'avoir un endroit central comme celui-ci pour 93 00:04:54,740 --> 00:04:56,560 ‫gérer tous les refus de 94 00:04:56,560 --> 00:04:59,132 ‫promesse comme un dernier filet de sécurité, d'accord ? 95 00:04:59,132 --> 00:05:01,800 ‫Maintenant, si nous avons vraiment un problème avec 96 00:05:01,800 --> 00:05:04,890 ‫la connexion à la base de données, comme dans cet 97 00:05:04,890 --> 00:05:07,840 ‫exemple, alors notre application ne fonctionnera pas du tout. 98 00:05:07,840 --> 00:05:09,760 ‫Et donc tout ce que nous 99 00:05:09,760 --> 00:05:12,820 ‫pouvons vraiment faire ici est de fermer notre application, d'accord ? 100 00:05:12,820 --> 00:05:17,053 ‫Donc, pour arrêter l'application, nous utilisons process. sortir. 101 00:05:18,140 --> 00:05:20,420 ‫Et nous avons déjà utilisé cela auparavant 102 00:05:20,420 --> 00:05:22,850 ‫dans ce script où nous avons importé toutes les 103 00:05:22,850 --> 00:05:27,080 ‫données dans la base de données à partir du fichier JSON, vous vous souvenez ? 104 00:05:27,080 --> 00:05:29,660 ‫Donc processus. exit et puis 105 00:05:29,660 --> 00:05:31,810 ‫ici, nous pouvons réellement passer un code. 106 00:05:31,810 --> 00:05:34,140 ‫Et le code zéro représente un 107 00:05:34,140 --> 00:05:36,800 ‫succès et un représente une exception non capturée. 108 00:05:36,800 --> 00:05:40,230 ‫Et c'est donc celui qui est habituellement utilisé ici, d'accord ? 109 00:05:40,230 --> 00:05:43,400 ‫Donc généralement, vous le verrez toujours comme ça. 110 00:05:43,400 --> 00:05:46,970 ‫Et ajoutons juste comme un journal ici, console. log unhandler le 111 00:05:50,293 --> 00:05:51,973 ‫rejet, quelque chose 112 00:05:56,020 --> 00:05:57,560 ‫comme ça. 113 00:05:57,560 --> 00:05:59,860 ‫Alors vous voyez, j'aime beaucoup celui-ci, celui-ci ici. 114 00:06:02,910 --> 00:06:04,650 ‫Laissant juste ce nœud... 115 00:06:04,650 --> 00:06:06,730 ‫Pas vraiment utilisateur, mais 116 00:06:06,730 --> 00:06:09,320 ‫notre journal que nous fermons, d'accord ? 117 00:06:09,320 --> 00:06:12,330 ‫Et maintenant, vous voyez que l'application s'est réellement écrasée. 118 00:06:12,330 --> 00:06:16,515 ‫Et c'est à cause de ce processus. sors d'ici, d'accord ? 119 00:06:16,515 --> 00:06:18,860 ‫Maintenant, il y a juste un problème avec la 120 00:06:18,860 --> 00:06:20,480 ‫façon dont nous l'avons mis 121 00:06:20,480 --> 00:06:23,430 ‫en œuvre en ce moment et c'est que la façon dont 122 00:06:23,430 --> 00:06:26,990 ‫nous l'implémentons ici est donc juste. exit est une manière 123 00:06:26,990 --> 00:06:30,420 ‫très abrupte de terminer le programme car cela 124 00:06:30,420 --> 00:06:34,030 ‫annulera immédiatement toutes les requêtes en cours d'exécution ou en 125 00:06:34,030 --> 00:06:38,300 ‫attente et ce n'est donc peut-être pas une bonne idée, d'accord ? 126 00:06:38,300 --> 00:06:41,550 ‫Et donc généralement, ce que nous faisons, c'est arrêter gracieusement 127 00:06:41,550 --> 00:06:44,210 ‫là où nous fermons d'abord le serveur 128 00:06:44,210 --> 00:06:47,140 ‫et seulement ensuite, nous arrêtons l'application, d'accord ? 129 00:06:47,140 --> 00:06:47,973 ‫Alors allons... 130 00:06:47,973 --> 00:06:51,440 ‫Avant de faire cela, nous devons enregistrer 131 00:06:51,440 --> 00:06:55,670 ‫le serveur ici essentiellement dans une variable, d'accord ? 132 00:06:55,670 --> 00:06:59,650 ‫Et donc le résultat de l'appel de l'application. listen est un serveur et jusqu'à 133 00:06:59,650 --> 00:07:04,650 ‫présent, sur ce serveur, on peut alors dire serveur. close qui, comme son nom l'indique, 134 00:07:05,810 --> 00:07:08,400 ‫fermera le serveur, puis après cela, 135 00:07:08,400 --> 00:07:10,490 ‫il exécutera cette fonction 136 00:07:10,490 --> 00:07:14,810 ‫de rappel que nous lui avons transmise et ce n'est 137 00:07:14,810 --> 00:07:16,130 ‫donc qu'ici, 138 00:07:16,130 --> 00:07:19,310 ‫où nous arrêtons ensuite le serveur, d'accord ? 139 00:07:19,310 --> 00:07:22,240 ‫Et donc en faisant cela, en faisant server. close, nous donnons 140 00:07:22,240 --> 00:07:25,630 ‫au serveur le temps de terminer toutes les demandes encore 141 00:07:25,630 --> 00:07:28,890 ‫en attente ou en cours de traitement à ce moment-là, 142 00:07:28,890 --> 00:07:31,180 ‫et seulement après cela, le serveur est 143 00:07:31,180 --> 00:07:32,910 ‫alors pratiquement tué, d'accord ? 144 00:07:32,910 --> 00:07:34,620 ‫Donc, quand nous lui donnons 145 00:07:34,620 --> 00:07:37,020 ‫un coffre-fort, il n'aura pas exactement la même 146 00:07:37,020 --> 00:07:39,880 ‫apparence parce que, (rires) ouais, nous sommes comme les seuls 147 00:07:39,880 --> 00:07:42,850 ‫qui accèdent vraiment à cette application mais dans le scénario du 148 00:07:42,850 --> 00:07:45,960 ‫monde réel, nous devrions toujours le faire comme ça, d'accord ? 149 00:07:45,960 --> 00:07:48,200 ‫Et bien sûr, ce n'est pas 150 00:07:48,200 --> 00:07:50,520 ‫vraiment idéal que l'application plante, non ? 151 00:07:50,520 --> 00:07:53,120 ‫Parce qu'en ce moment, bien sûr, l'application ne fonctionne pas, elle 152 00:07:53,120 --> 00:07:55,448 ‫ne fonctionne pas du tout, n'est-ce pas ? 153 00:07:55,448 --> 00:07:59,570 ‫Et donc généralement, dans une application de production sur un serveur Web, nous 154 00:07:59,570 --> 00:08:01,690 ‫aurons généralement un outil en place qui 155 00:08:01,690 --> 00:08:05,100 ‫redémarre l'application juste après son crash, ou également certaines des plates-formes 156 00:08:05,100 --> 00:08:08,120 ‫qui hébergent le nœud. js le 157 00:08:08,120 --> 00:08:11,164 ‫fera automatiquement tout seul, d'accord ? 158 00:08:11,164 --> 00:08:13,920 ‫Parce que, bien sûr, nous ne voulons pas laisser l'application 159 00:08:13,920 --> 00:08:15,590 ‫suspendue comme ça pour toujours. 160 00:08:15,590 --> 00:08:18,420 ‫Donc ce n'est pas utile non plus, d'accord ? 161 00:08:18,420 --> 00:08:20,410 ‫Et donc, fondamentalement, c'est ainsi que 162 00:08:20,410 --> 00:08:22,590 ‫vous gérez les promesses rejetées non gérées. 163 00:08:22,590 --> 00:08:25,130 ‫Donc, encore une fois, en gros, nous écoutons 164 00:08:25,130 --> 00:08:27,930 ‫cet événement de rejet non géré, ce qui nous 165 00:08:27,930 --> 00:08:30,100 ‫permet ensuite de gérer toutes 166 00:08:30,100 --> 00:08:32,280 ‫les erreurs qui se produisent dans le 167 00:08:32,280 --> 00:08:34,470 ‫code asynchrone qui n'étaient pas gérées auparavant. 168 00:08:34,470 --> 00:08:38,050 ‫Mais maintenant, vous pourriez demander, qu'en est-il du code synchrone ? 169 00:08:38,050 --> 00:08:40,110 ‫Où allons-nous gérer ça? 170 00:08:40,110 --> 00:08:43,020 ‫Et la réponse à cela se trouve, comme vous pouvez 171 00:08:43,020 --> 00:08:44,523 ‫l'imaginer, dans la vidéo suivante.