1
00:00:00,860 --> 00:00:03,680
‫Instructor: Bienvenido de nuevo, ahora, antes de

2
00:00:03,680 --> 00:00:06,820
‫profundizar en el manejo real de errores, primero escriba

3
00:00:06,820 --> 00:00:09,430
‫un controlador para rutas no definidas.

4
00:00:09,430 --> 00:00:12,250
‫Básicamente, para rutas que aún no asignamos

5
00:00:12,250 --> 00:00:13,403
‫ningún controlador.

6
00:00:14,800 --> 00:00:17,820
‫Y primero, debemos iniciar nuestra aplicación aquí, que

7
00:00:17,820 --> 00:00:21,053
‫no cerramos después de la sesión de depuración reciente.

8
00:00:21,950 --> 00:00:23,363
‫Entonces MPM comienza.

9
00:00:25,260 --> 00:00:28,290
‫Y entonces esperemos una conexión a la base de datos.

10
00:00:28,290 --> 00:00:33,290
‫Aquí está, así que vayamos ahora a Postman e intentemos encontrar

11
00:00:33,640 --> 00:00:36,810
‫la ruta que aún no definimos.

12
00:00:36,810 --> 00:00:39,793
‫Así que seguiré adelante, copiaré esta

13
00:00:41,892 --> 00:00:44,260
‫URL aquí, de acuerdo, y

14
00:00:44,260 --> 00:00:46,410
‫por ejemplo, digamos que

15
00:00:48,240 --> 00:00:49,490
‫en lugar

16
00:00:49,490 --> 00:00:53,223
‫de apiV1 tours, diríamos solo api / tours.

17
00:00:54,140 --> 00:00:58,400
‫De acuerdo, en ese caso obtendríamos este resultado HTML, de

18
00:00:58,400 --> 00:01:01,470
‫acuerdo, entonces Express envía automáticamente este

19
00:01:01,470 --> 00:01:05,380
‫código HTML aquí, junto con un código de error 404

20
00:01:05,380 --> 00:01:08,700
‫No encontrado en caso de que no haya

21
00:01:08,700 --> 00:01:12,900
‫ningún controlador para la ruta que se solicitó, de acuerdo.

22
00:01:12,900 --> 00:01:16,483
‫O, también podríamos simplemente escribir mal el tour aquí, por ejemplo.

23
00:01:17,640 --> 00:01:19,850
‫Entonces, por ejemplo, en este caso

24
00:01:19,850 --> 00:01:21,840
‫todavía obtendríamos el mismo error.

25
00:01:21,840 --> 00:01:25,210
‫Ahora también hay otra situación que es

26
00:01:25,210 --> 00:01:29,580
‫si aquí después de las giras especificamos algo más,

27
00:01:29,580 --> 00:01:31,800
‫digamos algo como esto.

28
00:01:31,800 --> 00:01:34,790
‫Entonces, echemos un vistazo al error que obtenemos,

29
00:01:34,790 --> 00:01:38,470
‫y ahora obtenemos que la conversión a ID de objeto falló.

30
00:01:38,470 --> 00:01:40,560
‫Y eso se debe a que

31
00:01:40,560 --> 00:01:45,390
‫en realidad tenemos una ruta que acepta un parámetro de ID aquí después del recorrido /, ¿no?

32
00:01:45,390 --> 00:01:48,770
‫Y entonces MongoDB básicamente está tratando de encontrar un

33
00:01:48,770 --> 00:01:53,180
‫documento con este ID, pero no puede convertirlo en un ID de

34
00:01:53,180 --> 00:01:55,160
‫objeto MongoDB válido, de acuerdo.

35
00:01:55,160 --> 00:01:58,810
‫Nuevamente, esa es una situación diferente, sigamos trabajando con

36
00:01:59,820 --> 00:02:02,930
‫esta, así que nuevamente, donde obtenemos este error,

37
00:02:02,930 --> 00:02:05,550
‫pero en este formulario HTML.

38
00:02:05,550 --> 00:02:08,330
‫Ahora que estamos haciendo una API aquí,

39
00:02:08,330 --> 00:02:12,070
‫no tiene mucho sentido devolver HTML, correcto, así que ahora

40
00:02:12,070 --> 00:02:15,400
‫arreglemos esto y básicamente creemos una función de manejo

41
00:02:15,400 --> 00:02:19,270
‫para todas las rutas que nuestros enrutadores no almacenan en caché.

42
00:02:19,270 --> 00:02:22,610
‫Bien, volvamos a nuestra aplicación aquí y

43
00:02:22,610 --> 00:02:25,540
‫abramos la aplicación. js.

44
00:02:25,540 --> 00:02:27,950
‫Bien, esa es básicamente la definición

45
00:02:27,950 --> 00:02:30,180
‫de nuestra aplicación Express.

46
00:02:30,180 --> 00:02:32,530
‫Ahora, antes de hacer cualquier

47
00:02:32,530 --> 00:02:35,190
‫otra cosa, eliminemos este middleware que

48
00:02:35,190 --> 00:02:36,700
‫ya no necesitamos.

49
00:02:36,700 --> 00:02:39,360
‫Así que usamos esto aquí para demostrar

50
00:02:39,360 --> 00:02:43,160
‫el concepto de middleware, por lo que en este punto

51
00:02:43,160 --> 00:02:45,080
‫ya no lo necesitamos.

52
00:02:45,080 --> 00:02:47,980
‫Muy bien ahora, ¿cómo vamos a implementar un controlador de

53
00:02:47,980 --> 00:02:51,410
‫ruta para una ruta que no fue almacenada en caché por ninguno

54
00:02:51,410 --> 00:02:53,380
‫de nuestros otros controladores de ruta?

55
00:02:53,380 --> 00:02:56,160
‫Entonces, para hacer eso, recuerde que todas estas funciones

56
00:02:56,160 --> 00:02:59,770
‫de middleware se ejecutan en el orden en que están en el código.

57
00:02:59,770 --> 00:03:02,930
‫Entonces, la idea es que si tenemos una

58
00:03:02,930 --> 00:03:06,210
‫solicitud que llega a este punto aquí de nuestro

59
00:03:06,210 --> 00:03:08,760
‫código, entonces significa que ni

60
00:03:08,760 --> 00:03:12,860
‫el tourRouter ni el userRouter pudieron almacenarlo en caché, de acuerdo.

61
00:03:12,860 --> 00:03:16,590
‫Entonces, si agregamos un middleware aquí después de estos enrutadores, solo

62
00:03:16,590 --> 00:03:20,060
‫se volverá a acceder si no lo maneja ninguno

63
00:03:20,060 --> 00:03:22,470
‫de nuestros otros enrutadores, está bien.

64
00:03:22,470 --> 00:03:25,610
‫Así que hagámoslo y luego entendamos realmente cómo funciona después

65
00:03:25,610 --> 00:03:27,550
‫de que ya esté implementado.

66
00:03:27,550 --> 00:03:29,600
‫Así que vamos a implementar un controlador de

67
00:03:29,600 --> 00:03:30,923
‫ruta, entonces decimos app.

68
00:03:32,450 --> 00:03:34,540
‫y ahora el método HTTP para el

69
00:03:34,540 --> 00:03:36,380
‫que queremos especificar la ruta.

70
00:03:36,380 --> 00:03:40,630
‫Ahora podríamos usar get here right, así como lo hicimos antes, pero

71
00:03:40,630 --> 00:03:43,410
‫¿qué pasa con las solicitudes de publicación, eliminación

72
00:03:43,410 --> 00:03:45,030
‫o revisión de solicitudes?

73
00:03:45,030 --> 00:03:47,730
‫Entonces tendrías que escribir controladores para estos también,

74
00:03:47,730 --> 00:03:50,190
‫y no queremos eso, simplemente queremos manejar

75
00:03:50,190 --> 00:03:54,270
‫todas las rutas, así que todas las URL, para todos los verbos

76
00:03:54,270 --> 00:03:56,707
‫aquí en este controlador, está bien.

77
00:03:56,707 --> 00:03:59,710
‫Y entonces en Express, podemos usar app. todos.

78
00:03:59,710 --> 00:04:02,460
‫Y entonces eso se ejecutará para todos los

79
00:04:02,460 --> 00:04:05,430
‫verbos, así que todo el método HTTP, está bien.

80
00:04:05,430 --> 00:04:08,270
‫A continuación, especificamos la URL, y dado que aquí

81
00:04:08,270 --> 00:04:10,920
‫queremos manejar todas las URL que no se

82
00:04:10,920 --> 00:04:13,950
‫manejaron antes, podemos usar la estrella aquí, que va

83
00:04:13,950 --> 00:04:17,320
‫a representar todo, está bien, y luego el resto es

84
00:04:17,320 --> 00:04:19,920
‫solo una función de middleware normal ,

85
00:04:19,920 --> 00:04:21,183
‫justo como antes.

86
00:04:23,980 --> 00:04:24,893
‫Así que

87
00:04:26,210 --> 00:04:27,883
‫solicite, responda y luego.

88
00:04:29,270 --> 00:04:32,290
‫Está bien, ¿y qué queremos hacer aquí?

89
00:04:32,290 --> 00:04:34,700
‫Bueno, simplemente queremos enviar una

90
00:04:34,700 --> 00:04:38,653
‫respuesta en formato JSON, no el HTML que tenemos ahora.

91
00:04:40,100 --> 00:04:41,573
‫Entonces res. status,

92
00:04:43,100 --> 00:04:46,110
‫y aquí establezcamos un 404, por lo que No

93
00:04:48,220 --> 00:04:52,190
‫encontrado y luego una respuesta JSON, al igual que el habitual

94
00:04:52,190 --> 00:04:54,343
‫donde configuramos el estado para fallar.

95
00:04:57,090 --> 00:05:01,153
‫Entonces, solo una respuesta formateada adyacente regular.

96
00:05:03,590 --> 00:05:05,980
‫Y luego algún tipo de mensaje aquí, y de

97
00:05:05,980 --> 00:05:07,580
‫hecho hagamos una cadena de

98
00:05:07,580 --> 00:05:09,790
‫plantilla aquí, porque quiero poner una variable allí.

99
00:05:09,790 --> 00:05:11,370
‫Así que no puedo

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

101
00:05:13,380 --> 00:05:16,650
‫Y luego podemos usar req. originalUrl está bien, así

102
00:05:18,220 --> 00:05:21,900
‫que esa es una propiedad que tenemos en la

103
00:05:21,900 --> 00:05:26,233
‫solicitud, que es como dice el nombre, la URL que se solicitó,

104
00:05:27,300 --> 00:05:28,270
‫de acuerdo.

105
00:05:28,270 --> 00:05:30,610
‫Entonces, esta nueva respuesta que

106
00:05:30,610 --> 00:05:33,230
‫vamos a enviar ahora es mucho mejor

107
00:05:33,230 --> 00:05:37,163
‫que el HTML que recibíamos anteriormente, así que ahora probemos eso.

108
00:05:40,440 --> 00:05:44,020
‫Y, de hecho, ahora recibimos un mensaje de error JSON aquí.

109
00:05:44,020 --> 00:05:47,970
‫Y aquí también obtenemos la URL que se solicitó,

110
00:05:47,970 --> 00:05:50,586
‫y de hecho es la

111
00:05:50,586 --> 00:05:54,760
‫que intentamos acceder, pero no está disponible, está bien, genial.

112
00:05:54,760 --> 00:05:57,240
‫Ahora de nuevo, ¿por qué funcionó esto?

113
00:05:57,240 --> 00:06:01,200
‫Entonces, nuevamente, la idea es que si podemos llegar a este punto

114
00:06:01,200 --> 00:06:04,120
‫aquí, significa que el ciclo de respuesta a

115
00:06:04,120 --> 00:06:06,281
‫la solicitud aún no ha

116
00:06:06,281 --> 00:06:09,100
‫terminado en este punto de nuestro código, ¿verdad?

117
00:06:09,100 --> 00:06:11,780
‫Porque recuerde que el middleware se agrega a la

118
00:06:11,780 --> 00:06:14,040
‫pila de middleware en el orden en que

119
00:06:14,040 --> 00:06:16,010
‫se define aquí en nuestro código.

120
00:06:16,010 --> 00:06:18,810
‫Básicamente, este código aquí se ejecuta primero,

121
00:06:18,810 --> 00:06:21,840
‫por lo que si la ruta coincidiera aquí

122
00:06:21,840 --> 00:06:25,230
‫en nuestro tourRouter, nuestra solicitud nunca llegaría a este código,

123
00:06:25,230 --> 00:06:27,660
‫por lo que no se ejecutaría.

124
00:06:27,660 --> 00:06:30,050
‫Y esta debería ser básicamente la última

125
00:06:30,050 --> 00:06:32,560
‫parte después de todas nuestras otras rutas, de acuerdo.

126
00:06:32,560 --> 00:06:35,240
‫Y si lo fuera, solo

127
00:06:35,240 --> 00:06:38,140
‫para probar esto, ahora coloque esto en

128
00:06:39,230 --> 00:06:43,260
‫la parte superior de nuestra aplicación, entonces verá que

129
00:06:43,260 --> 00:06:47,750
‫no importa qué solicitud hagamos, siempre obtendremos la misma respuesta.

130
00:06:47,750 --> 00:06:49,653
‫Bien, probemos eso, y

131
00:06:51,550 --> 00:06:54,600
‫de hecho ahora obtenemos un mensaje de error JS,

132
00:06:54,600 --> 00:06:56,600
‫y eso es porque todas las

133
00:06:56,600 --> 00:06:59,850
‫solicitudes ahora llegan a este controlador de ruta aquí, y

134
00:06:59,850 --> 00:07:04,290
‫en realidad coincide porque es una solicitud GET, que es parte de todos los

135
00:07:04,290 --> 00:07:08,060
‫verbos, correcto, y luego todas las rutas, por lo que todas las

136
00:07:08,060 --> 00:07:10,760
‫URL se almacenan en caché aquí y, por

137
00:07:10,760 --> 00:07:13,920
‫supuesto, maneja esa URL que acabamos de hacer aquí.

138
00:07:13,920 --> 00:07:17,333
‫Y lo mismo, por supuesto, por ejemplo para eliminar un recorrido.

139
00:07:18,330 --> 00:07:20,590
‫Entonces sucedería lo mismo, siempre

140
00:07:20,590 --> 00:07:22,573
‫obtendríamos la misma respuesta, de

141
00:07:23,740 --> 00:07:24,573
‫acuerdo.

142
00:07:25,430 --> 00:07:28,500
‫Así que, por supuesto, volvamos a

143
00:07:28,500 --> 00:07:33,183
‫ponerlo, pero esto fue solo para demostrar cómo y por qué

144
00:07:34,100 --> 00:07:35,670
‫funciona, de acuerdo.

145
00:07:35,670 --> 00:07:38,890
‫Genial, esta es una parte importante para hacer que nuestra API

146
00:07:38,890 --> 00:07:42,150
‫sea un poco más fácil de usar, pero a continuación, comencemos

147
00:07:42,150 --> 00:07:44,873
‫a aprender sobre el manejo de errores reales.