1
00:00:01,120 --> 00:00:03,120
‫Instructor: En este video, hablemos de

2
00:00:03,120 --> 00:00:06,770
‫algo que tenemos en node. js llamados rechazos no

3
00:00:06,770 --> 00:00:09,543
‫controlados y luego aprendamos cómo podemos realmente manejarlos.

4
00:00:10,970 --> 00:00:14,400
‫Entonces, en este punto, hemos manejado con éxito

5
00:00:14,400 --> 00:00:16,330
‫los errores en

6
00:00:16,330 --> 00:00:19,970
‫nuestra aplicación express pasando errores operativos asíncronos a un

7
00:00:19,970 --> 00:00:22,410
‫middleware de manejo de errores global.

8
00:00:22,410 --> 00:00:26,200
‫Esto, luego envía mensajes de error relevantes

9
00:00:26,200 --> 00:00:30,510
‫al cliente dependiendo del tipo de error que ocurrió, ¿verdad?

10
00:00:30,510 --> 00:00:34,730
‫Sin embargo, también pueden ocurrir errores fuera de express y un buen

11
00:00:34,730 --> 00:00:38,520
‫ejemplo de eso en nuestra aplicación actual es la conexión

12
00:00:38,520 --> 00:00:40,810
‫de base de datos mongodb.

13
00:00:40,810 --> 00:00:43,700
‫Así que imagine que la base de datos está inactiva por alguna

14
00:00:43,700 --> 00:00:46,000
‫razón o por alguna razón, no podemos iniciar sesión.

15
00:00:46,000 --> 00:00:47,920
‫Y en ese caso, también hay

16
00:00:47,920 --> 00:00:49,610
‫errores que tenemos que manejar.

17
00:00:49,610 --> 00:00:52,800
‫Pero no ocurrieron dentro de nuestra aplicación express

18
00:00:52,800 --> 00:00:55,810
‫y, por supuesto, nuestro controlador de errores que

19
00:00:55,810 --> 00:00:58,560
‫implementamos no detectará estos errores, ¿verdad?

20
00:00:58,560 --> 00:01:01,790
‫Entonces, solo para probar lo que sucede, sigamos

21
00:01:01,790 --> 00:01:05,110
‫adelante y cambiemos nuestra contraseña de mongodb, ¿de acuerdo?

22
00:01:05,110 --> 00:01:06,960
‫Porque de esa manera,

23
00:01:06,960 --> 00:01:10,180
‫no podremos conectarnos a la base de datos, ¿verdad?

24
00:01:10,180 --> 00:01:13,110
‫Entonces deberíamos obtener algún tipo de error, así

25
00:01:13,110 --> 00:01:15,510
‫que vayamos aquí al archivo de

26
00:01:15,510 --> 00:01:18,633
‫nuestro servidor y lo guardemos para recargar nuestro servidor,

27
00:01:20,710 --> 00:01:23,040
‫aumentémoslo aquí, y de hecho,

28
00:01:23,040 --> 00:01:26,120
‫aquí tenemos un rechazo de promesa no manejado.

29
00:01:26,120 --> 00:01:29,510
‫Y ese es realmente el tema de este video.

30
00:01:29,510 --> 00:01:33,600
‫Entonces, un rechazo de promesa no manejada significa que en algún lugar

31
00:01:33,600 --> 00:01:37,140
‫de nuestro código, hay una promesa que fue rechazada.

32
00:01:37,140 --> 00:01:41,270
‫Pero ese rechazo no se ha manejado en ningún lado, ¿de acuerdo?

33
00:01:41,270 --> 00:01:44,920
‫Y aquí abajo, también verá una advertencia de desaprobación que dice

34
00:01:44,920 --> 00:01:48,008
‫que en el futuro los rechazos no manejados

35
00:01:48,008 --> 00:01:51,710
‫simplemente saldrán del programa de nodo que se está ejecutando, lo

36
00:01:51,710 --> 00:01:54,940
‫que puede no ser siempre lo que desea, ¿de acuerdo?

37
00:01:54,940 --> 00:01:57,450
‫Así que solucionemos este problema y

38
00:01:57,450 --> 00:02:00,000
‫eliminemos este rechazo de promesa no manejado.

39
00:02:00,000 --> 00:02:01,910
‫Ahora, en este simple ejemplo

40
00:02:01,910 --> 00:02:03,270
‫aquí, sería

41
00:02:03,270 --> 00:02:05,770
‫bastante fácil manejar ese rechazo, ¿verdad?

42
00:02:05,770 --> 00:02:08,060
‫Todo lo que tendremos que hacer será

43
00:02:08,060 --> 00:02:11,550
‫llegar aquí a este fragmento de código donde nuestra conexión está realmente hecha

44
00:02:11,550 --> 00:02:14,100
‫y luego, agregar un controlador de captura allí, ¿verdad?

45
00:02:14,100 --> 00:02:16,580
‫Así que un poco así, y luego

46
00:02:16,580 --> 00:02:18,640
‫aquí, podríamos manejar ese rechazo

47
00:02:18,640 --> 00:02:20,970
‫y entonces ya no obtendríamos este error.

48
00:02:20,970 --> 00:02:22,820
‫Déjame mostrarte eso rápidamente.

49
00:02:29,905 --> 00:02:31,960
‫Inténtelo de nuevo.

50
00:02:31,960 --> 00:02:35,630
‫Y ahora, obtiene un error que es, por supuesto, el

51
00:02:35,630 --> 00:02:37,950
‫resultado de este registro aquí, pero,

52
00:02:37,950 --> 00:02:41,010
‫por supuesto, no obtenemos ningún rechazo de promesa

53
00:02:41,010 --> 00:02:45,060
‫no manejada, nuevamente, porque en realidad lo manejamos aquí, ¿de acuerdo?

54
00:02:45,060 --> 00:02:48,580
‫Así que esto funcionaría, por supuesto, pero realmente quiero mostrarles cómo

55
00:02:48,580 --> 00:02:51,720
‫manejar globalmente las promesas rechazadas no manejadas, porque en una

56
00:02:51,720 --> 00:02:54,680
‫aplicación más grande, puede volverse un poco más difícil

57
00:02:54,680 --> 00:02:57,860
‫hacer un seguimiento de todas las promesas que podrían ser

58
00:02:57,860 --> 00:03:00,590
‫rechazadas en algún momento. punto, ¿de acuerdo?

59
00:03:00,590 --> 00:03:03,280
‫Entonces, en algún momento, es posible que tenga

60
00:03:03,280 --> 00:03:06,690
‫algún rechazo de promesa no manejado en algún lugar, así que

61
00:03:06,690 --> 00:03:09,860
‫permítame mostrarle cómo lidiar con eso a nivel mundial básicamente.

62
00:03:09,860 --> 00:03:14,070
‫Y ahora aprendamos cómo manejar los rechazos no manejados y

63
00:03:14,070 --> 00:03:16,160
‫lo haremos aquí mismo.

64
00:03:16,160 --> 00:03:19,530
‫Y entonces recuerda cómo en una de las primeras

65
00:03:19,530 --> 00:03:21,900
‫secciones del curso, hablamos sobre eventos

66
00:03:21,900 --> 00:03:24,080
‫y oyentes de eventos, ¿verdad?

67
00:03:24,080 --> 00:03:28,010
‫Y ahora, es el momento de utilizar ese conocimiento.

68
00:03:28,010 --> 00:03:30,940
‫Entonces, cada vez que hay un rechazo

69
00:03:30,940 --> 00:03:34,180
‫no controlado en algún lugar de nuestra aplicación, el

70
00:03:34,180 --> 00:03:37,470
‫objeto de proceso emitirá un objeto llamado rechazo no

71
00:03:37,470 --> 00:03:41,223
‫controlado y así podemos suscribirnos a ese evento de esta manera.

72
00:03:42,250 --> 00:03:46,903
‫Así que procesa. encendido, recuerde, y luego el

73
00:03:48,004 --> 00:03:52,053
‫nombre del evento, rechazo no controlado, y luego la

74
00:03:52,930 --> 00:03:55,240
‫función de devolución de

75
00:03:55,240 --> 00:03:59,369
‫llamada aquí recibe un error, así que sigamos adelante

76
00:03:59,369 --> 00:04:02,793
‫y registremos el error en la consola.

77
00:04:03,780 --> 00:04:08,653
‫Entonces usemos err. nombre y err. mensaje.

78
00:04:09,620 --> 00:04:11,640
‫Entonces, estos son algunos valores predeterminados que tenemos

79
00:04:12,500 --> 00:04:16,073
‫en todos los errores en node. js, ¿de acuerdo?

80
00:04:17,570 --> 00:04:20,930
‫Bien, y después de guardar, ya tenemos aquí

81
00:04:20,930 --> 00:04:24,410
‫el nombre del error y también el mensaje de error.

82
00:04:24,410 --> 00:04:27,940
‫Tan mala autenticación que se debe a que, por supuesto,

83
00:04:27,940 --> 00:04:29,490
‫tenemos la contraseña incorrecta.

84
00:04:29,490 --> 00:04:32,360
‫Y ahora mismo, el rechazo de la promesa no

85
00:04:32,360 --> 00:04:33,960
‫manejada ahora se maneja realmente.

86
00:04:33,960 --> 00:04:37,430
‫Y, por supuesto, no solo el de esta conexión fallida,

87
00:04:37,430 --> 00:04:40,410
‫sino cualquier otro rechazo de promesa que no podamos

88
00:04:40,410 --> 00:04:44,260
‫detectar en algún lugar de la aplicación se maneja aquí en esta

89
00:04:44,260 --> 00:04:46,880
‫final, llamémoslo red de seguridad, ¿de acuerdo?

90
00:04:46,880 --> 00:04:49,890
‫Así que siempre tenemos que asumir que nosotros,

91
00:04:49,890 --> 00:04:51,410
‫como programadores, cometeremos errores.

92
00:04:51,410 --> 00:04:54,740
‫Entonces, siempre es mejor tener un lugar central como este para

93
00:04:54,740 --> 00:04:56,560
‫manejar todos los rechazos de

94
00:04:56,560 --> 00:04:59,132
‫promesas como una última red de seguridad, ¿de acuerdo?

95
00:04:59,132 --> 00:05:01,800
‫Ahora, si realmente tenemos algún problema con

96
00:05:01,800 --> 00:05:04,890
‫la conexión de la base de datos, como tenemos en

97
00:05:04,890 --> 00:05:07,840
‫este ejemplo, entonces nuestra aplicación no funcionará en absoluto.

98
00:05:07,840 --> 00:05:09,760
‫Entonces, todo lo que podemos

99
00:05:09,760 --> 00:05:12,820
‫hacer aquí es cerrar nuestra aplicación, ¿de acuerdo?

100
00:05:12,820 --> 00:05:17,053
‫Entonces, para cerrar la aplicación, usamos process. Salida.

101
00:05:18,140 --> 00:05:20,420
‫Y de hecho ya lo usamos

102
00:05:20,420 --> 00:05:22,850
‫antes en ese script donde importamos todos

103
00:05:22,850 --> 00:05:27,080
‫los datos a la base de datos desde el archivo JSON, ¿recuerdas?

104
00:05:27,080 --> 00:05:29,660
‫Así que procesa. salir y luego

105
00:05:29,660 --> 00:05:31,810
‫aquí, podemos pasar un código.

106
00:05:31,810 --> 00:05:34,140
‫Y el código cero representa un éxito

107
00:05:34,140 --> 00:05:36,800
‫y el uno representa una excepción no detectada.

108
00:05:36,800 --> 00:05:40,230
‫Y ese es el que generalmente se usa aquí, ¿de acuerdo?

109
00:05:40,230 --> 00:05:43,400
‫Por lo general, siempre lo verá así.

110
00:05:43,400 --> 00:05:46,970
‫Y agreguemos como un registro aquí, consola. log unhandler el

111
00:05:50,293 --> 00:05:51,973
‫rechazo, algo como

112
00:05:56,020 --> 00:05:57,560
‫esto.

113
00:05:57,560 --> 00:05:59,860
‫Verá, me gusta mucho este, este de aquí.

114
00:06:02,910 --> 00:06:04,650
‫Dejando que esto sea un nodo ...

115
00:06:04,650 --> 00:06:06,730
‫No es realmente un usuario,

116
00:06:06,730 --> 00:06:09,320
‫sino nuestro registro que estamos cerrando, ¿de acuerdo?

117
00:06:09,320 --> 00:06:12,330
‫Y ahora, ves que la aplicación realmente se bloqueó.

118
00:06:12,330 --> 00:06:16,515
‫Y eso se debe a este proceso. salir de aquí, ¿de acuerdo?

119
00:06:16,515 --> 00:06:18,860
‫Ahora, solo hay un problema con la forma en

120
00:06:18,860 --> 00:06:20,480
‫que lo implementamos en este

121
00:06:20,480 --> 00:06:23,430
‫momento y es que la forma en que lo implementamos aquí

122
00:06:23,430 --> 00:06:26,990
‫es tan simple como el proceso. salir es una forma

123
00:06:26,990 --> 00:06:30,420
‫muy abrupta de finalizar el programa porque esto simplemente anulará

124
00:06:30,420 --> 00:06:34,030
‫inmediatamente todas las solicitudes que todavía están en ejecución o pendientes

125
00:06:34,030 --> 00:06:38,300
‫y, por lo tanto, puede que no sea una buena idea, ¿de acuerdo?

126
00:06:38,300 --> 00:06:41,550
‫Y, por lo general, lo que hacemos es cerrar

127
00:06:41,550 --> 00:06:44,210
‫correctamente donde primero cerramos el servidor

128
00:06:44,210 --> 00:06:47,140
‫y solo entonces, cerramos la aplicación, ¿de acuerdo?

129
00:06:47,140 --> 00:06:47,973
‫Entonces vamos...

130
00:06:47,973 --> 00:06:51,440
‫Antes de hacer eso, necesitamos guardar

131
00:06:51,440 --> 00:06:55,670
‫el servidor aquí básicamente en una variable, ¿de acuerdo?

132
00:06:55,670 --> 00:06:59,650
‫Y así, el resultado de llamar a app. listen es un servidor y

133
00:06:59,650 --> 00:07:04,650
‫ahora, en ese servidor, podemos decir servidor. close que, como dice el nombre,

134
00:07:05,810 --> 00:07:08,400
‫cerrará el servidor y luego, una

135
00:07:08,400 --> 00:07:10,490
‫vez hecho esto, ejecutará esta

136
00:07:10,490 --> 00:07:14,810
‫función de devolución de llamada que le pasamos y, por lo

137
00:07:14,810 --> 00:07:16,130
‫tanto, solo

138
00:07:16,130 --> 00:07:19,310
‫está aquí, donde apagamos el servidor, ¿de acuerdo?

139
00:07:19,310 --> 00:07:22,240
‫Y así, al hacer esto, al hacer server. cerrar, le damos

140
00:07:22,240 --> 00:07:25,630
‫al servidor, básicamente, tiempo para finalizar todas las solicitudes que

141
00:07:25,630 --> 00:07:28,890
‫aún están pendientes o en proceso en ese momento,

142
00:07:28,890 --> 00:07:31,180
‫y solo después de eso, el servidor

143
00:07:31,180 --> 00:07:32,910
‫básicamente se mata, ¿de acuerdo?

144
00:07:32,910 --> 00:07:34,620
‫Entonces, cuando le demos

145
00:07:34,620 --> 00:07:37,020
‫una caja fuerte, no se verá exactamente

146
00:07:37,020 --> 00:07:39,880
‫igual porque, (risas) sí, somos los únicos que

147
00:07:39,880 --> 00:07:42,850
‫realmente acceden a esta aplicación, pero en el escenario

148
00:07:42,850 --> 00:07:45,960
‫del mundo real, siempre deberíamos hacerlo así, de acuerdo. ?

149
00:07:45,960 --> 00:07:48,200
‫Y, por supuesto, no es realmente

150
00:07:48,200 --> 00:07:50,520
‫ideal que la aplicación se bloquee, ¿verdad?

151
00:07:50,520 --> 00:07:53,120
‫Porque en este momento, por supuesto, la aplicación no

152
00:07:53,120 --> 00:07:55,448
‫se está ejecutando, no funciona en absoluto, ¿verdad?

153
00:07:55,448 --> 00:07:59,570
‫Y, por lo general, en una aplicación de producción en un servidor web, generalmente

154
00:07:59,570 --> 00:08:01,690
‫tendremos alguna herramienta que reinicia la aplicación

155
00:08:01,690 --> 00:08:05,100
‫justo después de que falla, o también algunas de las plataformas

156
00:08:05,100 --> 00:08:08,120
‫que albergan el nodo. js lo

157
00:08:08,120 --> 00:08:11,164
‫hará automáticamente por su cuenta, ¿de acuerdo?

158
00:08:11,164 --> 00:08:13,920
‫Porque, por supuesto, no queremos dejar la aplicación

159
00:08:13,920 --> 00:08:15,590
‫colgando así para siempre.

160
00:08:15,590 --> 00:08:18,420
‫Entonces eso tampoco es útil, ¿de acuerdo?

161
00:08:18,420 --> 00:08:20,410
‫Básicamente, así es como

162
00:08:20,410 --> 00:08:22,590
‫maneja las promesas rechazadas no manejadas.

163
00:08:22,590 --> 00:08:25,130
‫Entonces, nuevamente, básicamente, estamos escuchando este evento

164
00:08:25,130 --> 00:08:27,930
‫de rechazo no controlado, que luego nos permite

165
00:08:27,930 --> 00:08:30,100
‫manejar todos los errores

166
00:08:30,100 --> 00:08:32,280
‫que ocurren en el código

167
00:08:32,280 --> 00:08:34,470
‫asincrónico que no fueron manejados previamente.

168
00:08:34,470 --> 00:08:38,050
‫Pero ahora, podría preguntar, ¿qué pasa con el código síncrono?

169
00:08:38,050 --> 00:08:40,110
‫¿Dónde vamos a manejar eso?

170
00:08:40,110 --> 00:08:43,020
‫Y la respuesta a eso se encuentra, como puedes imaginar,

171
00:08:43,020 --> 00:08:44,523
‫en el siguiente video.