‫Jonas: En este video, implementaremos
‫algo de lógica para enviar diferentes mensajes de
‫error para el entorno de desarrollo y producción.
‫Entonces, en este momento, estamos enviando este mismo mensaje de respuesta
‫aquí básicamente a todos, sin importar si estamos en
‫desarrollo o en producción.
‫Pero la idea es que en producción queremos filtrar
‫la menor cantidad de información posible
‫sobre nuestros errores al cliente.
‫Entonces, en ese caso, solo queremos enviar
‫un mensaje agradable y amigable
‫para que el usuario sepa lo que está mal.
‫Por otro lado, cuando se
‫escribe desarrollo, queremos obtener la mayor cantidad de información
‫posible sobre el error que ocurrió, y lo queremos
‫en el mensaje de error que está regresando.
‫Así que podríamos registrar esa información también en
‫la consola, pero creo que es mucho más útil tener
‫esa información directamente en el cartero, en este caso.
‫Entonces, ya sabemos cómo distinguir entre el
‫desarrollo y el entorno de producción.
‫Y entonces, hagámoslo.
‫Entonces,
‫si process. env. node_env es
‫igual a desarrollo, entonces queremos
‫enviar un tipo de
‫error y, si
‫estamos en producción, queremos enviar un error más simple.
‫Bien.
‫Tan igual a la producción.
‫Muy bien, tomemos este, así que nuevamente,
‫cuando escribamos el
‫desarrollo, queremos obtener toda la información que podamos.
‫Entonces eso también imprime o responde con la pila de errores aquí.
‫Así que err. stack, y luego
‫imprimamos también el error completo.
‫Digamos error y configúrelo bien.
‫Luego, por
‫otro lado, ahora copiemos esto nuevamente.
‫Cuando estamos en producción, no queremos la pila
‫y tampoco queremos el error completo.
‫Así que realmente solo el estado y el mensaje.
‫Esto aquí se ve
‫un poco desordenado, así que exportémoslos a sus
‫propias funciones y también porque en realidad vamos
‫a agregar mucho más código aquí, en esta rama else.
‫Es un poco más limpio tener estos en sus
‫propias funciones separadas.
‫Entonces, digamos
‫const send error for dev
‫y esa función debería recibir el error,
‫y también debemos pasar el asunto de la respuesta.
‫Eso es porque así es como podemos
‫enviar la respuesta, ¿verdad?
‫Entonces necesitamos el asunto de la respuesta para poder ejecutar
‫este código.
‫Aquí solo vamos a llamar a
‫send error dev
‫con el
‫error y la respuesta.
‫Luego, aquí
‫abajo, tendremos
‫producción de error de
‫envío,
‫los mismos argumentos.
‫Y luego aquí, lo mismo.
‫Así que fue fácil, ahora vayamos al siguiente nivel
‫y hablemos de los errores operativos nuevamente.
‫Para eso, permítanme abrir la clase de error
‫de la aplicación que creamos, y recordemos
‫que marcamos todos
‫los errores que creamos, usando AppError es operativo establecido en verdadero.
‫Entonces, todos los errores que
‫creamos nosotros mismos serán básicamente errores operativos.
‫De hecho, son solo estos errores operativos los
‫que queremos enviar el mensaje de error
‫al cliente.
‫Al menos en producción.
‫Entonces, cuando nosotros, por otro lado, tenemos un error de programación,
‫o algún otro error desconocido que
‫proviene, por ejemplo, de un paquete de
‫terceros, no queremos enviar ningún mensaje de error sobre eso
‫al cliente en producción.
‫Y eso es inútil.
‫Esta es la propiedad operativa aquí en nuestro controlador de errores.
‫Recuerda que ya hablé de
‫hacer eso cuando creamos esta clase, ¿verdad?
‫Ahora vengamos aquí para enviar la producción de errores y
‫hacer esa prueba.
‫Si error. isOperational solo
‫en ese caso queremos enviar este error aquí.
‫En todos
‫los demás casos, simplemente
‫enviaremos un mensaje de error muy genérico al cliente.
‫Entonces digamos, res. status y simplemente
‫enviaremos un código 500 genérico y
‫luego json.
‫El estado será error.
‫Entonces enviemos un mensaje genérico, diciendo que
‫algo
‫salió muy mal.
‫Entonces, hacer algo como esto es un procedimiento muy estándar.
‫Permítanme comentar algo del código aquí.
‫Así que este es un error operativo en el que confiamos.
‫Aquí queremos enviar un mensaje al cliente.
‫Pero en este
‫caso aquí, tenemos un error
‫desconocido, por lo que no queremos filtrar los detalles al cliente.
‫Entonces, solo enviaremos este mensaje al cliente y
‫también a nosotros mismos.
‫Para nosotros, los desarrolladores, queremos
‫saber que ocurrió este tipo de error extraño, inesperado
‫y desconocido y lo vamos a registrar en la consola.
‫Primero registraremos el
‫error y luego enviaremos un mensaje genérico.
‫Digamos que consola. error, por lo que esto es
‫un poco como console. log, pero
‫es realmente específico para errores y creo
‫que la salida se verá un poco diferente.
‫Entonces, error, agreguemos algunos emoji aquí para que sea visible
‫en nuestros
‫registros, y luego registremos el error también.
‫Ahora hay bibliotecas de registro reales en mpm, que podríamos
‫usar aquí en
‫lugar de tener esta simple consola. error, pero el simple hecho
‫de registrar el error en la consola lo
‫hará visible en los registros de
‫la plataforma de alojamiento que está utilizando.
‫Creo que por ahora, en este tipo de aplicación simple,
‫es suficiente.
‫Por ejemplo, usaremos Heroku
‫al final del curso para implementar nuestra aplicación.
‫Luego, cuando ocurra un error
‫como este, se registrará en la consola.
‫En la plataforma Heroku, tenemos acceso a estos registros.
‫Podemos seguir mirando estos registros, y luego
‫encontraremos estos errores inesperados para
‫poder corregirlos.
‫En este momento, ya estamos construyendo aquí una
‫especie de mecanismo de manejo de errores sofisticado
‫y del mundo real.
‫Así que recapitulemos rápidamente lo que acabamos de hacer aquí.
‫Distinguimos entre errores en el desarrollo y en
‫la producción.
‫Cuando estamos en producción, enviamos el error
‫usando esta función aquí,
‫que luego enviará tantos detalles como sea posible
‫al cliente,
‫para que realmente obtengamos
‫toda la información para deshacernos del error.
‫Si es un error
‫de programación, o si es un error
‫operativo, entonces realmente queremos ver todo lo que está sucediendo.
‫Cuando estamos en
‫producción, que es posiblemente la parte
‫más importante de nuestra aplicación, distinguimos entre
‫errores operativos, es decir,
‫errores que conocemos y en los
‫que confiamos, y otros errores que pueden ser inesperados.
‫Si el error es operativo, por ejemplo, el usuario intentó
‫acceder a una ruta que no existe, o
‫intentó ingresar datos no válidos, todos
‫estos son errores operativos.
‫Luego, podemos enviar los mensajes de error apropiados para
‫que el cliente sepa qué salió mal.
‫Por otro lado, tenemos estos errores desconocidos,
‫o errores inesperados, y en
‫ese caso, simplemente decimos que algo salió mal.
‫Luego, registre el error también en nuestra
‫consola, para que sepamos que sucedió y luego podamos solucionarlo.
‫Ahora bien, para que esto
‫funcione, hay algo realmente importante que
‫debemos hacer.
‫Ahora mismo hay errores que
‫vienen, por ejemplo, de MongoDB, que no marcamos como operativos.
‫En este caso, en este momento simplemente se manejarían usando
‫este mensaje de error genérico aquí.
‫Por ejemplo, un error de validación.
‫En este momento, ese es un error que proviene
‫de MongoDB y no de nuestra propia clase de error de aplicación.
‫No creamos estos errores por nosotros mismos.
‫Nuevamente, en este momento no están marcados como operativos,
‫pero, por supuesto, debemos marcarlos como operativos para
‫poder enviar el mensaje de error
‫correspondiente al cliente.
‫En el ejemplo que acabo de mencionar, los
‫datos de entrada no son válidos.
‫Hay otros dos o tres errores que debemos marcar
‫como operativos nosotros mismos.
‫Así que
‫haremos eso aquí abajo.
‫Entonces, en este bloque
‫else, lo haremos en las próximas conferencias.