1 00:00:01,150 --> 00:00:03,353 ‫Jonas: En este video, implementaremos 2 00:00:03,353 --> 00:00:06,390 ‫algo de lógica para enviar diferentes mensajes de 3 00:00:06,390 --> 00:00:09,173 ‫error para el entorno de desarrollo y producción. 4 00:00:10,810 --> 00:00:14,490 ‫Entonces, en este momento, estamos enviando este mismo mensaje de respuesta 5 00:00:14,490 --> 00:00:17,389 ‫aquí básicamente a todos, sin importar si estamos en 6 00:00:17,389 --> 00:00:18,920 ‫desarrollo o en producción. 7 00:00:18,920 --> 00:00:21,690 ‫Pero la idea es que en producción queremos filtrar 8 00:00:21,690 --> 00:00:23,810 ‫la menor cantidad de información posible 9 00:00:23,810 --> 00:00:25,583 ‫sobre nuestros errores al cliente. 10 00:00:26,420 --> 00:00:28,490 ‫Entonces, en ese caso, solo queremos enviar 11 00:00:28,490 --> 00:00:30,340 ‫un mensaje agradable y amigable 12 00:00:30,340 --> 00:00:33,070 ‫para que el usuario sepa lo que está mal. 13 00:00:33,070 --> 00:00:34,858 ‫Por otro lado, cuando se 14 00:00:34,858 --> 00:00:37,700 ‫escribe desarrollo, queremos obtener la mayor cantidad de información 15 00:00:37,700 --> 00:00:40,390 ‫posible sobre el error que ocurrió, y lo queremos 16 00:00:40,390 --> 00:00:42,950 ‫en el mensaje de error que está regresando. 17 00:00:42,950 --> 00:00:45,520 ‫Así que podríamos registrar esa información también en 18 00:00:45,520 --> 00:00:48,340 ‫la consola, pero creo que es mucho más útil tener 19 00:00:48,340 --> 00:00:51,150 ‫esa información directamente en el cartero, en este caso. 20 00:00:51,150 --> 00:00:53,660 ‫Entonces, ya sabemos cómo distinguir entre el 21 00:00:53,660 --> 00:00:56,010 ‫desarrollo y el entorno de producción. 22 00:00:56,870 --> 00:00:58,213 ‫Y entonces, hagámoslo. 23 00:00:59,130 --> 00:00:59,963 ‫Entonces, 24 00:01:01,630 --> 00:01:05,010 ‫si process. env. node_env es 25 00:01:06,510 --> 00:01:08,970 ‫igual a desarrollo, entonces queremos 26 00:01:11,810 --> 00:01:13,780 ‫enviar un tipo de 27 00:01:15,530 --> 00:01:17,060 ‫error y, si 28 00:01:17,060 --> 00:01:21,020 ‫estamos en producción, queremos enviar un error más simple. 29 00:01:21,020 --> 00:01:21,853 ‫Bien. 30 00:01:24,290 --> 00:01:26,913 ‫Tan igual a la producción. 31 00:01:30,160 --> 00:01:33,343 ‫Muy bien, tomemos este, así que nuevamente, 32 00:01:34,390 --> 00:01:36,380 ‫cuando escribamos el 33 00:01:36,380 --> 00:01:39,850 ‫desarrollo, queremos obtener toda la información que podamos. 34 00:01:39,850 --> 00:01:43,763 ‫Entonces eso también imprime o responde con la pila de errores aquí. 35 00:01:48,620 --> 00:01:52,300 ‫Así que err. stack, y luego 36 00:01:52,300 --> 00:01:54,483 ‫imprimamos también el error completo. 37 00:01:56,240 --> 00:02:00,830 ‫Digamos error y configúrelo bien. 38 00:02:00,830 --> 00:02:02,003 ‫Luego, por 39 00:02:03,030 --> 00:02:05,183 ‫otro lado, ahora copiemos esto nuevamente. 40 00:02:06,040 --> 00:02:09,350 ‫Cuando estamos en producción, no queremos la pila 41 00:02:09,350 --> 00:02:12,493 ‫y tampoco queremos el error completo. 42 00:02:13,490 --> 00:02:16,113 ‫Así que realmente solo el estado y el mensaje. 43 00:02:19,190 --> 00:02:20,933 ‫Esto aquí se ve 44 00:02:21,930 --> 00:02:24,550 ‫un poco desordenado, así que exportémoslos a sus 45 00:02:24,550 --> 00:02:27,440 ‫propias funciones y también porque en realidad vamos 46 00:02:27,440 --> 00:02:30,719 ‫a agregar mucho más código aquí, en esta rama else. 47 00:02:30,719 --> 00:02:33,730 ‫Es un poco más limpio tener estos en sus 48 00:02:33,730 --> 00:02:35,180 ‫propias funciones separadas. 49 00:02:36,500 --> 00:02:37,550 ‫Entonces, digamos 50 00:02:39,540 --> 00:02:41,480 ‫const send error for dev 51 00:02:43,930 --> 00:02:46,470 ‫y esa función debería recibir el error, 52 00:02:46,470 --> 00:02:49,903 ‫y también debemos pasar el asunto de la respuesta. 53 00:02:51,990 --> 00:02:54,930 ‫Eso es porque así es como podemos 54 00:02:54,930 --> 00:02:57,223 ‫enviar la respuesta, ¿verdad? 55 00:02:58,360 --> 00:03:02,090 ‫Entonces necesitamos el asunto de la respuesta para poder ejecutar 56 00:03:02,090 --> 00:03:02,933 ‫este código. 57 00:03:04,080 --> 00:03:06,510 ‫Aquí solo vamos a llamar a 58 00:03:07,410 --> 00:03:08,990 ‫send error dev 59 00:03:09,890 --> 00:03:11,263 ‫con el 60 00:03:11,263 --> 00:03:13,073 ‫error y la respuesta. 61 00:03:14,270 --> 00:03:15,483 ‫Luego, aquí 62 00:03:17,030 --> 00:03:18,030 ‫abajo, tendremos 63 00:03:18,030 --> 00:03:19,850 ‫producción de error de 64 00:03:20,900 --> 00:03:21,783 ‫envío, 65 00:03:24,830 --> 00:03:26,253 ‫los mismos argumentos. 66 00:03:36,300 --> 00:03:37,500 ‫Y luego aquí, lo mismo. 67 00:03:43,041 --> 00:03:46,740 ‫Así que fue fácil, ahora vayamos al siguiente nivel 68 00:03:46,740 --> 00:03:49,810 ‫y hablemos de los errores operativos nuevamente. 69 00:03:49,810 --> 00:03:53,230 ‫Para eso, permítanme abrir la clase de error 70 00:03:53,230 --> 00:03:56,270 ‫de la aplicación que creamos, y recordemos 71 00:03:56,270 --> 00:03:57,870 ‫que marcamos todos 72 00:03:57,870 --> 00:04:02,313 ‫los errores que creamos, usando AppError es operativo establecido en verdadero. 73 00:04:03,721 --> 00:04:05,760 ‫Entonces, todos los errores que 74 00:04:05,760 --> 00:04:07,873 ‫creamos nosotros mismos serán básicamente errores operativos. 75 00:04:09,100 --> 00:04:11,950 ‫De hecho, son solo estos errores operativos los 76 00:04:11,950 --> 00:04:14,540 ‫que queremos enviar el mensaje de error 77 00:04:14,540 --> 00:04:15,703 ‫al cliente. 78 00:04:16,720 --> 00:04:18,310 ‫Al menos en producción. 79 00:04:18,310 --> 00:04:21,900 ‫Entonces, cuando nosotros, por otro lado, tenemos un error de programación, 80 00:04:21,900 --> 00:04:23,880 ‫o algún otro error desconocido que 81 00:04:23,880 --> 00:04:26,500 ‫proviene, por ejemplo, de un paquete de 82 00:04:26,500 --> 00:04:29,930 ‫terceros, no queremos enviar ningún mensaje de error sobre eso 83 00:04:29,930 --> 00:04:31,864 ‫al cliente en producción. 84 00:04:31,864 --> 00:04:33,470 ‫Y eso es inútil. 85 00:04:33,470 --> 00:04:37,340 ‫Esta es la propiedad operativa aquí en nuestro controlador de errores. 86 00:04:37,340 --> 00:04:40,090 ‫Recuerda que ya hablé de 87 00:04:40,090 --> 00:04:43,693 ‫hacer eso cuando creamos esta clase, ¿verdad? 88 00:04:45,580 --> 00:04:48,780 ‫Ahora vengamos aquí para enviar la producción de errores y 89 00:04:49,730 --> 00:04:50,913 ‫hacer esa prueba. 90 00:04:52,270 --> 00:04:54,787 ‫Si error. isOperational solo 91 00:05:00,630 --> 00:05:05,053 ‫en ese caso queremos enviar este error aquí. 92 00:05:06,940 --> 00:05:08,113 ‫En todos 93 00:05:10,070 --> 00:05:11,330 ‫los demás casos, simplemente 94 00:05:11,330 --> 00:05:14,580 ‫enviaremos un mensaje de error muy genérico al cliente. 95 00:05:14,580 --> 00:05:17,310 ‫Entonces digamos, res. status y simplemente 96 00:05:19,400 --> 00:05:22,110 ‫enviaremos un código 500 genérico y 97 00:05:23,930 --> 00:05:25,123 ‫luego json. 98 00:05:28,120 --> 00:05:30,363 ‫El estado será error. 99 00:05:33,230 --> 00:05:36,660 ‫Entonces enviemos un mensaje genérico, diciendo que 100 00:05:38,200 --> 00:05:39,033 ‫algo 101 00:05:41,360 --> 00:05:42,573 ‫salió muy mal. 102 00:05:43,690 --> 00:05:46,983 ‫Entonces, hacer algo como esto es un procedimiento muy estándar. 103 00:05:48,420 --> 00:05:51,133 ‫Permítanme comentar algo del código aquí. 104 00:05:54,530 --> 00:05:57,533 ‫Así que este es un error operativo en el que confiamos. 105 00:06:03,700 --> 00:06:06,200 ‫Aquí queremos enviar un mensaje al cliente. 106 00:06:06,200 --> 00:06:07,503 ‫Pero en este 107 00:06:16,130 --> 00:06:17,973 ‫caso aquí, tenemos un error 108 00:06:19,080 --> 00:06:22,673 ‫desconocido, por lo que no queremos filtrar los detalles al cliente. 109 00:06:28,470 --> 00:06:31,380 ‫Entonces, solo enviaremos este mensaje al cliente y 110 00:06:31,380 --> 00:06:33,070 ‫también a nosotros mismos. 111 00:06:33,070 --> 00:06:35,340 ‫Para nosotros, los desarrolladores, queremos 112 00:06:35,340 --> 00:06:38,610 ‫saber que ocurrió este tipo de error extraño, inesperado 113 00:06:38,610 --> 00:06:41,993 ‫y desconocido y lo vamos a registrar en la consola. 114 00:06:49,100 --> 00:06:50,593 ‫Primero registraremos el 115 00:06:56,702 --> 00:06:59,369 ‫error y luego enviaremos un mensaje genérico. 116 00:07:00,280 --> 00:07:03,270 ‫Digamos que consola. error, por lo que esto es 117 00:07:03,270 --> 00:07:05,490 ‫un poco como console. log, pero 118 00:07:05,490 --> 00:07:07,870 ‫es realmente específico para errores y creo 119 00:07:07,870 --> 00:07:10,670 ‫que la salida se verá un poco diferente. 120 00:07:12,090 --> 00:07:15,670 ‫Entonces, error, agreguemos algunos emoji aquí para que sea visible 121 00:07:15,670 --> 00:07:16,543 ‫en nuestros 122 00:07:17,950 --> 00:07:20,360 ‫registros, y luego registremos el error también. 123 00:07:20,360 --> 00:07:23,213 ‫Ahora hay bibliotecas de registro reales en mpm, que podríamos 124 00:07:23,213 --> 00:07:24,550 ‫usar aquí en 125 00:07:24,550 --> 00:07:28,030 ‫lugar de tener esta simple consola. error, pero el simple hecho 126 00:07:28,030 --> 00:07:30,430 ‫de registrar el error en la consola lo 127 00:07:30,430 --> 00:07:32,220 ‫hará visible en los registros de 128 00:07:32,220 --> 00:07:34,363 ‫la plataforma de alojamiento que está utilizando. 129 00:07:35,486 --> 00:07:39,200 ‫Creo que por ahora, en este tipo de aplicación simple, 130 00:07:39,200 --> 00:07:40,073 ‫es suficiente. 131 00:07:41,110 --> 00:07:42,860 ‫Por ejemplo, usaremos Heroku 132 00:07:42,860 --> 00:07:45,710 ‫al final del curso para implementar nuestra aplicación. 133 00:07:45,710 --> 00:07:47,600 ‫Luego, cuando ocurra un error 134 00:07:47,600 --> 00:07:49,970 ‫como este, se registrará en la consola. 135 00:07:49,970 --> 00:07:54,180 ‫En la plataforma Heroku, tenemos acceso a estos registros. 136 00:07:54,180 --> 00:07:57,080 ‫Podemos seguir mirando estos registros, y luego 137 00:07:57,080 --> 00:07:59,220 ‫encontraremos estos errores inesperados para 138 00:07:59,220 --> 00:08:00,670 ‫poder corregirlos. 139 00:08:01,678 --> 00:08:04,470 ‫En este momento, ya estamos construyendo aquí una 140 00:08:04,470 --> 00:08:07,000 ‫especie de mecanismo de manejo de errores sofisticado 141 00:08:07,000 --> 00:08:08,713 ‫y del mundo real. 142 00:08:09,720 --> 00:08:13,240 ‫Así que recapitulemos rápidamente lo que acabamos de hacer aquí. 143 00:08:13,240 --> 00:08:16,380 ‫Distinguimos entre errores en el desarrollo y en 144 00:08:16,380 --> 00:08:17,373 ‫la producción. 145 00:08:18,720 --> 00:08:21,420 ‫Cuando estamos en producción, enviamos el error 146 00:08:21,420 --> 00:08:22,970 ‫usando esta función aquí, 147 00:08:22,970 --> 00:08:26,050 ‫que luego enviará tantos detalles como sea posible 148 00:08:26,050 --> 00:08:27,340 ‫al cliente, 149 00:08:27,340 --> 00:08:28,997 ‫para que realmente obtengamos 150 00:08:28,997 --> 00:08:31,730 ‫toda la información para deshacernos del error. 151 00:08:31,730 --> 00:08:33,332 ‫Si es un error 152 00:08:33,332 --> 00:08:35,670 ‫de programación, o si es un error 153 00:08:35,670 --> 00:08:39,083 ‫operativo, entonces realmente queremos ver todo lo que está sucediendo. 154 00:08:40,670 --> 00:08:42,000 ‫Cuando estamos en 155 00:08:42,000 --> 00:08:44,330 ‫producción, que es posiblemente la parte 156 00:08:44,330 --> 00:08:47,090 ‫más importante de nuestra aplicación, distinguimos entre 157 00:08:47,090 --> 00:08:48,590 ‫errores operativos, es decir, 158 00:08:48,590 --> 00:08:50,950 ‫errores que conocemos y en los 159 00:08:50,950 --> 00:08:54,163 ‫que confiamos, y otros errores que pueden ser inesperados. 160 00:08:55,660 --> 00:08:58,800 ‫Si el error es operativo, por ejemplo, el usuario intentó 161 00:08:58,800 --> 00:09:01,530 ‫acceder a una ruta que no existe, o 162 00:09:01,530 --> 00:09:03,680 ‫intentó ingresar datos no válidos, todos 163 00:09:03,680 --> 00:09:05,253 ‫estos son errores operativos. 164 00:09:05,253 --> 00:09:08,130 ‫Luego, podemos enviar los mensajes de error apropiados para 165 00:09:08,130 --> 00:09:10,880 ‫que el cliente sepa qué salió mal. 166 00:09:10,880 --> 00:09:13,820 ‫Por otro lado, tenemos estos errores desconocidos, 167 00:09:13,820 --> 00:09:16,380 ‫o errores inesperados, y en 168 00:09:16,380 --> 00:09:19,420 ‫ese caso, simplemente decimos que algo salió mal. 169 00:09:19,420 --> 00:09:21,670 ‫Luego, registre el error también en nuestra 170 00:09:21,670 --> 00:09:24,433 ‫consola, para que sepamos que sucedió y luego podamos solucionarlo. 171 00:09:25,510 --> 00:09:27,080 ‫Ahora bien, para que esto 172 00:09:27,080 --> 00:09:29,160 ‫funcione, hay algo realmente importante que 173 00:09:29,160 --> 00:09:30,193 ‫debemos hacer. 174 00:09:31,040 --> 00:09:33,340 ‫Ahora mismo hay errores que 175 00:09:33,340 --> 00:09:37,550 ‫vienen, por ejemplo, de MongoDB, que no marcamos como operativos. 176 00:09:37,550 --> 00:09:40,970 ‫En este caso, en este momento simplemente se manejarían usando 177 00:09:40,970 --> 00:09:43,500 ‫este mensaje de error genérico aquí. 178 00:09:43,500 --> 00:09:45,330 ‫Por ejemplo, un error de validación. 179 00:09:45,330 --> 00:09:48,000 ‫En este momento, ese es un error que proviene 180 00:09:48,000 --> 00:09:51,356 ‫de MongoDB y no de nuestra propia clase de error de aplicación. 181 00:09:51,356 --> 00:09:54,869 ‫No creamos estos errores por nosotros mismos. 182 00:09:54,869 --> 00:09:58,800 ‫Nuevamente, en este momento no están marcados como operativos, 183 00:09:58,800 --> 00:10:02,130 ‫pero, por supuesto, debemos marcarlos como operativos para 184 00:10:02,130 --> 00:10:04,680 ‫poder enviar el mensaje de error 185 00:10:04,680 --> 00:10:06,400 ‫correspondiente al cliente. 186 00:10:06,400 --> 00:10:08,360 ‫En el ejemplo que acabo de mencionar, los 187 00:10:08,360 --> 00:10:10,263 ‫datos de entrada no son válidos. 188 00:10:11,250 --> 00:10:14,230 ‫Hay otros dos o tres errores que debemos marcar 189 00:10:14,230 --> 00:10:15,793 ‫como operativos nosotros mismos. 190 00:10:16,930 --> 00:10:18,020 ‫Así que 191 00:10:19,410 --> 00:10:20,670 ‫haremos eso aquí abajo. 192 00:10:20,670 --> 00:10:22,193 ‫Entonces, en este bloque 193 00:10:23,400 --> 00:10:25,850 ‫else, lo haremos en las próximas conferencias.