1
00:00:00,860 --> 00:00:03,680
‫Instructeur : Bienvenue à nouveau, maintenant, avant

2
00:00:03,680 --> 00:00:06,820
‫d'approfondir la gestion des erreurs, écrivons d'abord un

3
00:00:06,820 --> 00:00:09,430
‫gestionnaire pour les routes non définies.

4
00:00:09,430 --> 00:00:12,250
‫Donc en gros pour les routes auxquelles nous n'avons pas

5
00:00:12,250 --> 00:00:13,403
‫encore assigné de gestionnaire.

6
00:00:14,800 --> 00:00:17,820
‫Et tout d'abord, nous devons démarrer notre application ici,

7
00:00:17,820 --> 00:00:21,053
‫que nous n'avons pas quittée après la récente session de débogage.

8
00:00:21,950 --> 00:00:23,363
‫Alors MPM commence.

9
00:00:25,260 --> 00:00:28,290
‫Et attendons donc une connexion à la base de données.

10
00:00:28,290 --> 00:00:33,290
‫Le voici, et allons maintenant à Postman ici et essayons de suivre la

11
00:00:33,640 --> 00:00:36,810
‫route que nous n'avons pas encore définie.

12
00:00:36,810 --> 00:00:39,793
‫Donc je vais juste aller de l'avant,

13
00:00:41,892 --> 00:00:44,260
‫copier cette URL ici, d'accord,

14
00:00:44,260 --> 00:00:46,410
‫et donc par exemple

15
00:00:48,240 --> 00:00:49,490
‫disons qu'au

16
00:00:49,490 --> 00:00:53,223
‫lieu de tours apiV1, nous dirions juste api/tours.

17
00:00:54,140 --> 00:00:58,400
‫D'accord, dans ce cas, nous obtiendrions ce résultat HTML,

18
00:00:58,400 --> 00:01:01,470
‫d'accord, donc Express envoie automatiquement

19
00:01:01,470 --> 00:01:05,380
‫ce code HTML ici, ainsi qu'un code d'erreur

20
00:01:05,380 --> 00:01:08,700
‫404 Not Found au cas où il

21
00:01:08,700 --> 00:01:12,900
‫n'y aurait pas de gestionnaire pour l'itinéraire demandé, d'accord.

22
00:01:12,900 --> 00:01:16,483
‫Ou, nous pourrions aussi simplement orthographier tour ici par exemple.

23
00:01:17,640 --> 00:01:19,850
‫Ainsi, par exemple, dans ce cas, nous

24
00:01:19,850 --> 00:01:21,840
‫obtiendrions toujours la même erreur.

25
00:01:21,840 --> 00:01:25,210
‫Maintenant, il y a aussi une autre situation qui

26
00:01:25,210 --> 00:01:29,580
‫est si ici après les tournées nous spécifions autre chose, disons

27
00:01:29,580 --> 00:01:31,800
‫juste quelque chose comme ça.

28
00:01:31,800 --> 00:01:34,790
‫Et donc jetons un coup d'œil à l'erreur que nous

29
00:01:34,790 --> 00:01:38,470
‫obtenons, et maintenant nous obtenons que la conversion en ID d'objet a échoué.

30
00:01:38,470 --> 00:01:40,560
‫Et c'est parce que nous avons

31
00:01:40,560 --> 00:01:45,390
‫en fait un itinéraire qui accepte un paramètre ID ici après le tour/, à droite.

32
00:01:45,390 --> 00:01:48,770
‫Et donc MongoDB essaie essentiellement de trouver un document

33
00:01:48,770 --> 00:01:53,180
‫avec cet ID, mais ne peut pas le convertir en un ID

34
00:01:53,180 --> 00:01:55,160
‫d'objet MongoDB valide, d'accord.

35
00:01:55,160 --> 00:01:58,810
‫Encore une fois, c'est une situation différente, continuons simplement à travailler

36
00:01:59,820 --> 00:02:02,930
‫avec celui-ci, donc encore une fois, où nous obtenons

37
00:02:02,930 --> 00:02:05,550
‫cette erreur mais sous cette forme HTML.

38
00:02:05,550 --> 00:02:08,330
‫Maintenant, puisque nous faisons une API ici, cela

39
00:02:08,330 --> 00:02:12,070
‫n'a pas beaucoup de sens de renvoyer du HTML, d'accord, et donc

40
00:02:12,070 --> 00:02:15,400
‫réparons maintenant cela et créons essentiellement une fonction de gestion pour

41
00:02:15,400 --> 00:02:19,270
‫toutes les routes qui ne sont pas mises en cache par nos routeurs.

42
00:02:19,270 --> 00:02:22,610
‫Bon, revenons à notre application ici et

43
00:02:22,610 --> 00:02:25,540
‫ouvrons l'application. js.

44
00:02:25,540 --> 00:02:27,950
‫D'accord, c'est donc essentiellement la définition

45
00:02:27,950 --> 00:02:30,180
‫de notre application Express.

46
00:02:30,180 --> 00:02:32,530
‫Maintenant, avant de faire quoi que ce

47
00:02:32,530 --> 00:02:35,190
‫soit d'autre, débarrassons-nous en fait de ce middleware dont

48
00:02:35,190 --> 00:02:36,700
‫nous n'avons plus besoin.

49
00:02:36,700 --> 00:02:39,360
‫Nous l'avons donc utilisé ici pour démontrer

50
00:02:39,360 --> 00:02:43,160
‫le concept de middleware, et donc à ce stade, nous

51
00:02:43,160 --> 00:02:45,080
‫n'en avons plus besoin.

52
00:02:45,080 --> 00:02:47,980
‫Très bien maintenant, comment allons-nous implémenter un gestionnaire de route

53
00:02:47,980 --> 00:02:51,410
‫pour une route qui n'a été mise en cache par aucun de

54
00:02:51,410 --> 00:02:53,380
‫nos autres gestionnaires de route ?

55
00:02:53,380 --> 00:02:56,160
‫Donc, pour ce faire, rappelez-vous que toutes ces fonctions

56
00:02:56,160 --> 00:02:59,770
‫middleware sont exécutées dans l'ordre dans lequel elles se trouvent dans le code.

57
00:02:59,770 --> 00:03:02,930
‫Et donc, l'idée est que si nous avons une

58
00:03:02,930 --> 00:03:06,210
‫requête qui en fait ce point ici de notre

59
00:03:06,210 --> 00:03:08,760
‫code, cela signifie que ni le

60
00:03:08,760 --> 00:03:12,860
‫tourRouter ni le userRouter n'ont pu le mettre en cache, d'accord.

61
00:03:12,860 --> 00:03:16,590
‫Et donc, si nous ajoutons un middleware ici après ces routeurs,

62
00:03:16,590 --> 00:03:20,060
‫il ne sera à nouveau atteint que s'il n'est géré par

63
00:03:20,060 --> 00:03:22,470
‫aucun de nos autres routeurs, d'accord.

64
00:03:22,470 --> 00:03:25,610
‫Faisons-le, puis comprenons vraiment comment cela fonctionne une fois qu'il

65
00:03:25,610 --> 00:03:27,550
‫est déjà mis en œuvre.

66
00:03:27,550 --> 00:03:29,600
‫Nous allons donc implémenter un gestionnaire de route,

67
00:03:29,600 --> 00:03:30,923
‫et donc nous disons app.

68
00:03:32,450 --> 00:03:34,540
‫et maintenant la méthode HTTP pour laquelle

69
00:03:34,540 --> 00:03:36,380
‫nous voulons spécifier la route.

70
00:03:36,380 --> 00:03:40,630
‫Maintenant, nous pourrions utiliser get here right, alors comme nous l'avons fait auparavant,

71
00:03:40,630 --> 00:03:43,410
‫mais qu'en est-il des demandes de publication, de

72
00:03:43,410 --> 00:03:45,030
‫suppression ou de correctif?

73
00:03:45,030 --> 00:03:47,730
‫Vous devrez alors également écrire des gestionnaires pour

74
00:03:47,730 --> 00:03:50,190
‫ceux-ci, et nous ne voulons pas cela, nous

75
00:03:50,190 --> 00:03:54,270
‫voulons simplement gérer toutes les routes, donc toutes les URL, pour tous les

76
00:03:54,270 --> 00:03:56,707
‫verbes ici dans ce gestionnaire, d'accord.

77
00:03:56,707 --> 00:03:59,710
‫Et donc dans Express, nous pouvons utiliser app. tous.

78
00:03:59,710 --> 00:04:02,460
‫Et donc ça va s'exécuter pour tous

79
00:04:02,460 --> 00:04:05,430
‫les verbes, donc toute la méthode HTTP, d'accord.

80
00:04:05,430 --> 00:04:08,270
‫Ensuite, nous spécifions l'URL, et puisqu'ici nous

81
00:04:08,270 --> 00:04:10,920
‫voulons gérer toutes les URL qui n'ont

82
00:04:10,920 --> 00:04:13,950
‫pas été gérées avant de pouvoir utiliser l'étoile

83
00:04:13,950 --> 00:04:17,320
‫ici, qui va représenter tout, d'accord, et le reste

84
00:04:17,320 --> 00:04:19,920
‫n'est qu'une fonction middleware normale , juste

85
00:04:19,920 --> 00:04:21,183
‫comme avant.

86
00:04:23,980 --> 00:04:24,893
‫Donc

87
00:04:26,210 --> 00:04:27,883
‫demande, réponse, et ensuite.

88
00:04:29,270 --> 00:04:32,290
‫D'accord, et qu'est-ce qu'on veut faire ici ?

89
00:04:32,290 --> 00:04:34,700
‫Eh bien, nous voulons simplement renvoyer une

90
00:04:34,700 --> 00:04:38,653
‫réponse au format JSON, donc pas le HTML que nous avons actuellement.

91
00:04:40,100 --> 00:04:41,573
‫Donc rés. status,

92
00:04:43,100 --> 00:04:46,110
‫et ici, définissons un 404, donc Not Found,

93
00:04:48,220 --> 00:04:52,190
‫puis une réponse JSON, donc tout comme l'habituel où nous

94
00:04:52,190 --> 00:04:54,343
‫définissons le statut pour échouer.

95
00:04:57,090 --> 00:05:01,153
‫Donc juste une réponse formatée adjacente régulière.

96
00:05:03,590 --> 00:05:05,980
‫Et puis une sorte de message ici, et en

97
00:05:05,980 --> 00:05:07,580
‫fait, faisons une chaîne de

98
00:05:07,580 --> 00:05:09,790
‫modèle ici, car je veux y mettre une variable.

99
00:05:09,790 --> 00:05:11,370
‫Donc impossible,

100
00:05:11,370 --> 00:05:12,203
‫trouve.

101
00:05:13,380 --> 00:05:16,650
‫Et puis nous pouvons utiliser req. originalUrl d'accord, c'est donc

102
00:05:18,220 --> 00:05:21,900
‫une propriété que nous avons sur la demande qui

103
00:05:21,900 --> 00:05:26,233
‫est, comme son nom l'indique, l'URL qui a été demandée,

104
00:05:27,300 --> 00:05:28,270
‫d'accord.

105
00:05:28,270 --> 00:05:30,610
‫Donc, cette nouvelle réponse que

106
00:05:30,610 --> 00:05:33,230
‫nous allons renvoyer maintenant est bien meilleure

107
00:05:33,230 --> 00:05:37,163
‫que le HTML que nous recevions auparavant, alors testons-la maintenant.

108
00:05:40,440 --> 00:05:44,020
‫Et en effet, nous obtenons maintenant un message d'erreur JSON ici.

109
00:05:44,020 --> 00:05:47,970
‫Et donc ici, nous obtenons également l'URL qui a été demandée,

110
00:05:47,970 --> 00:05:50,586
‫et en effet c'est celle à

111
00:05:50,586 --> 00:05:54,760
‫laquelle nous avons essayé d'accéder, mais elle n'est pas disponible, d'accord, super.

112
00:05:54,760 --> 00:05:57,240
‫Maintenant encore, pourquoi cela a-t-il fonctionné ?

113
00:05:57,240 --> 00:06:01,200
‫Donc, encore une fois, l'idée est que si nous pouvons atteindre ce point

114
00:06:01,200 --> 00:06:04,120
‫ici, cela signifie que le cycle de réponse à

115
00:06:04,120 --> 00:06:06,281
‫la demande n'était pas encore terminé

116
00:06:06,281 --> 00:06:09,100
‫à ce stade de notre code, n'est-ce pas.

117
00:06:09,100 --> 00:06:11,780
‫Car rappelez-vous que le middleware est ajouté à

118
00:06:11,780 --> 00:06:14,040
‫la pile de middleware dans l'ordre

119
00:06:14,040 --> 00:06:16,010
‫défini ici dans notre code.

120
00:06:16,010 --> 00:06:18,810
‫Et donc fondamentalement, ce code ici s'exécute

121
00:06:18,810 --> 00:06:21,840
‫en premier, et donc si l'itinéraire correspondait ici dans

122
00:06:21,840 --> 00:06:25,230
‫notre tourRouter, notre demande n'atteindrait même jamais ce code, et

123
00:06:25,230 --> 00:06:27,660
‫donc cela ne serait pas exécuté.

124
00:06:27,660 --> 00:06:30,050
‫Et donc cela devrait être la

125
00:06:30,050 --> 00:06:32,560
‫dernière partie après tous nos autres itinéraires, d'accord.

126
00:06:32,560 --> 00:06:35,240
‫Et si je l'étais, juste pour

127
00:06:35,240 --> 00:06:38,140
‫essayer ceci, placez-le maintenant tout en haut

128
00:06:39,230 --> 00:06:43,260
‫de notre application, vous verrez que quelle que soit la

129
00:06:43,260 --> 00:06:47,750
‫demande que nous allons faire, nous obtiendrons toujours la même réponse.

130
00:06:47,750 --> 00:06:49,653
‫Bon, alors testons cela, et

131
00:06:51,550 --> 00:06:54,600
‫en effet maintenant nous obtenons un message d'erreur JS, et

132
00:06:54,600 --> 00:06:56,600
‫c'est parce que toutes les demandes

133
00:06:56,600 --> 00:06:59,850
‫atteignent maintenant ce gestionnaire de route ici, et il correspond en

134
00:06:59,850 --> 00:07:04,290
‫fait parce que c'est une demande GET, qui fait partie de tous les verbes,

135
00:07:04,290 --> 00:07:08,060
‫à droite, et puis toutes les routes, donc toutes les URL sont

136
00:07:08,060 --> 00:07:10,760
‫mises en cache ici, et donc bien sûr,

137
00:07:10,760 --> 00:07:13,920
‫il gère cette URL que nous venons de faire ici.

138
00:07:13,920 --> 00:07:17,333
‫Et la même chose bien sûr, par exemple pour une tournée de suppression.

139
00:07:18,330 --> 00:07:20,590
‫Donc la même chose se produirait,

140
00:07:20,590 --> 00:07:22,573
‫nous obtiendrions toujours la même

141
00:07:23,740 --> 00:07:24,573
‫réponse, d'accord.

142
00:07:25,430 --> 00:07:28,500
‫Alors, bien sûr, remettons-le en place,

143
00:07:28,500 --> 00:07:33,183
‫mais c'était juste pour montrer comment et pourquoi cela

144
00:07:34,100 --> 00:07:35,670
‫fonctionne, d'accord.

145
00:07:35,670 --> 00:07:38,890
‫Génial, c'est donc une partie importante pour rendre notre API

146
00:07:38,890 --> 00:07:42,150
‫un peu plus conviviale, mais commençons maintenant à en apprendre

147
00:07:42,150 --> 00:07:44,873
‫davantage sur la gestion des erreurs réelles.