Dominando el Manejo de Errores en Node.js

Hola a todos. Soy Liz Fardy, y soy la Jefa de Defensoría de Desarrolladores en una empresa muy interesante llamada Fusebit, enfocada en integraciones para desarrolladores. Gracias por asistir a mi charla. Hoy hablaré sobre cómo dominar la gestión de errores en Node.js. Este es mi nombre de usuario en Twitter, LizFardy23. Y si quieres crear integraciones increíbles, visita la cuenta de Twitter de Fusebit.io.

Siempre se debe tener en cuenta la gestión de errores al programar, porque todos queremos escribir código que funcione. Pero los errores ocurren en todas las aplicaciones, desde pequeñas startups hasta grandes empresas tecnológicas. Y los desarrolladores necesitan decidir qué hacer con esos errores. ¿Cómo los manejamos, los suprimimos, los ignoramos, tal vez notificamos a los usuarios, los informamos al equipo, los volvemos a intentar? Pero, ¿cuántas veces? Porque no se puede simplemente escribir código sin errores. Y eso es un hecho. Así que esta es la agenda de esta charla. Primero, veremos los tipos de errores, errores operativos y errores de programación, porque hay diferentes estrategias para los diferentes tipos de errores. Luego, veremos cómo manejar esos errores. Y finalmente, los patrones para mejorar la gestión de errores. Así que, comencemos.

Una gran parte de la programación consiste en encontrar y solucionar errores, por lo que es importante hacerlo como un profesional. A veces, al intentar solucionar un error, creamos tres más. Incluso podemos romper toda la aplicación. Por lo tanto, si conocemos las mejores prácticas de manejo de errores, es posible reducir el tiempo de depuración, mejorar el código, detectar errores más rápido y evitar crear más errores al solucionar un error.

Ahora, primero identifiquemos el tipo de errores. Podemos dividir todos los errores en dos categorías principales: errores operativos y errores de programación. Los errores operativos son problemas en tiempo de ejecución experimentados por un código bien escrito. Entonces, el código no tiene ningún problema, no hay errores. Estos errores son causados por algo más, algunas circunstancias externas que pueden interrumpir el flujo de ejecución del programa. Algunos ejemplos son el propio sistema, por ejemplo, cuando el sistema se queda sin memoria, la configuración del sistema, no hay ruta a un host remoto, tal vez porque el host está desconectado o si estás intentando conectarte al puerto incorrecto, la red, cuando experimentas problemas con los sockets, el servicio remoto, el error 500, que es el famoso error interno del servidor. Hay algo mal con el servidor que no es muy específico y no está relacionado con tu código, el internet o tu computadora. Es simplemente un error con el servidor. Fallo al conectarse al servidor, tal vez porque no tienes internet. Fallo al resolver el nombre de host cuando tienes un error tipográfico en el nombre de host al que estás intentando conectarte. Entrada de usuario no válida. Por ejemplo, el usuario necesita ingresar una dirección de correo electrónico pero el correo electrónico es inválido. O cualquier otra entrada no válida proporcionada por el usuario. Solicitar una aplicación. Por ejemplo, el servidor tardó demasiado tiempo en responder y falla. Se pierde una conexión de base de datos, tal vez debido a una conexión de red defectuosa. Este es un ejemplo de un sistema que opera en nuestra memoria, problemas con los sockets, pérdida de conexión de base de datos, entrada no válida, error 500 o error de servicio remoto, y sin WiFi, lo que puede causar fallo al conectarse al servidor. Cuando experimentas este tipo de errores, no hay mucho código que podamos hacer para solucionarlo. No se encuentra el archivo es un error operativo, pero eso no necesariamente significa que algo esté mal. Estas situaciones no surgen debido a errores en el código de la aplicación, pero deben manejarse correctamente. De lo contrario, podrían causar problemas más graves. Hay cinco técnicas principales para manejar los errores operativos. Primero, reintentar la operación. Si estás experimentando un error 500 o fallo al conectarse al servidor o el servidor está sobrecargado, puedes esperar y volver a intentar conectarte en unos segundos. Las solicitudes de red a servicios externos a veces pueden fallar, incluso si la solicitud es completamente válida. Estos problemas suelen ser esporádicos, por lo que en lugar de informarlos o notificarlos, puedes reintentar la solicitud varias veces hasta que tenga éxito o

La tercera técnica es notificar al cliente. Por ejemplo, si el error es causado por una entrada de usuario no válida, como una dirección de correo electrónico incorrecta, debes informar al cliente y asegurarte de incluir la información necesaria para construir el mensaje de error que tenga sentido para el usuario, como una dirección de correo electrónico no válida. Al tratar con entradas externas de usuarios, siempre debes asumir que la entrada es incorrecta de forma predeterminada. Valida la entrada antes de enviarla al usuario para que puedan corregirla antes de iniciar cualquier proceso de manejo de errores.

La siguiente técnica es abortar el programa. Otra solución es simplemente abortar la operación. En casos de errores del sistema irreparables, lo único que podemos hacer es bloquear el error y terminar el programa de inmediato. Limpia donde comenzaste y comienza de nuevo. Eso es todo.

Y finalmente, no hacer nada. Sí, simplemente no hacer nada. A veces, no hay nada que puedas hacer al respecto a un error operativo. No hay nada que reintentar o abortar. No hay razón para que el programa se bloquee. Un ejemplo podría ser si estás llevando un seguimiento de un grupo de servicios remotos utilizando DNS y uno de esos servicios desaparece del DNS. No hay nada que puedas hacer excepto registrar un mensaje y continuar con los servicios restantes. El manejo de errores se trata de qué falló y por qué. La distinción entre errores operativos y errores de programador es importante para determinar cómo entregar esos errores y manejarlos. Ahora veamos los errores de programador, que son los errores en los que los desarrolladores tienen control y se pueden solucionar con código. Los errores de programador son simplemente errores en el programa. Estos siempre se pueden evitar corrigiendo y cambiando el código o la lógica. Hay seis tipos de errores que se pueden encontrar en JavaScript. El primero es el error de tipo. Es un error cuando no se puede realizar una operación porque el valor no es del tipo esperado. Por ejemplo, cuando ves una propiedad de indefinido o pasas una cadena cuando se esperaba un objeto o no es una función requerida. En este caso, la variable del

Estos tres son los más comunes, pero hay otros tres que no son tan comunes, pero es útil conocerlos. El error de rango es un error que se produce cuando un valor numérico supera el rango permitido. Por ejemplo, si tengo un rango numérico de 10 a 20, los números que están fuera de este rango obtendrán un error de rango. O cuando se excede el tamaño máximo de la pila de llamadas, probablemente debido a un problema con una función recursiva dentro de tu código JavaScript. La función se sigue llamando a sí misma indefinidamente. Error de URI. Ocurre cuando se utilizan las funciones encode URI o decode URI de manera incorrecta. URI es un identificador uniforme de recursos. Por ejemplo, si quieres decodificar signos de porcentaje, lanzará un error de URI. Error de eval. Cuando usas la función eval de manera incorrecta. Esta excepción ya no se lanza en JavaScript. Ahora se utiliza el error de sintaxis en su lugar. Por eso no tengo un ejemplo aquí, porque probablemente nunca te encuentres con este error. El error de eval se mantiene por compatibilidad. Ahora que conocemos los seis tipos de errores de JavaScript que puedes encontrar, ¿cómo manejarlos? NodeJS admite varios mecanismos para manejar errores que ocurren mientras se ejecuta una aplicación. Cómo se informan y manejan estos errores depende completamente del tipo de error y del estilo de la API que se llama. Hay cuatro formas principales de entregar un error en NodeJS. La primera, excepciones. Capturan el error para operaciones síncronas. Devoluciones de llamada, pasan el error a una devolución de llamada. Una función proporcionada específicamente para manejar errores y el resultado de operaciones asíncronas. Rechazos de promesas, pasan el error a una función de rechazo de promesa usando async await.

Los emisores de eventos emiten un error en un emisor de eventos. Ahora veamos el primero. Las excepciones o lanzar el error es una forma muy común de entregar errores desde las funciones. Todos los errores de script de JS son excepciones que se generan y lanzan inmediatamente utilizando el mecanismo estándar de lanzamiento de JavaScript. Cuando lanzas un error, se convierte en una excepción y debe ser capturada en algún lugar de la pila utilizando un bloque try catch. Si se permite que el error se propague por la pila sin ser capturado, se convierte en una excepción no capturada que hace que la aplicación se cierre prematuramente. Como podemos ver en este ejemplo, si no hay un controlador, el proceso de no elección se cerrará inmediatamente. Mostraré un error de referencia porque z no está definido. Throw entrega un error de forma síncrona, es decir, en el mismo contexto donde se llamó la función. Si el llamador o los llamadores del llamador utilizan try catch, pueden capturar el error. En ninguno de los

Esta función de callback suele ser el último argumento de una función que inicia una operación asíncrona. Por ejemplo, el método real fight aquí espera una función de callback y su último argumento, y se llama una vez cuando ocurre un error y el resultado está disponible de la operación, por ejemplo, aquí al final en el registro de la consola. El primer argumento es el error. Si hay un error, estará disponible en el argumento de error, si no, los resultados contendrán el resultado esperado de la operación. Es importante controlar el flujo del contenido de la función de callback siempre verificando si hay un error antes de intentar acceder al resultado de la operación. Ignorar los errores no es seguro y no debes confiar en el contenido del resultado

Aquí tienes cómo puedes escuchar y react a cada evento emitido desde la función emitCount(). Como puedes ver aquí, la función de callback de cada escucha de evento se ejecuta indefinidamente tan pronto como se emite el evento, un segundo a la vez. El evento de error es un caso especial en Node.js porque si no hay un escucha para él, Node.js se bloqueará. Esto es lo que sucede cuando no pones el escucha de eventos de error y ejecutas el programa. Simplemente se bloquea. En su mayor parte, podemos agrupar los callbacks y los emisores de eventos en el mismo grupo de entrega de errores asíncronos. Si quieres entregar un error de forma asíncrona, generalmente quieres usar uno de los callbacks o el emisor de eventos, pero no ambos.

Finalmente, la última sesión de esta charla, que son patrones para mejorar el manejo de errores. El primero es usar clases de error. Creando una clase de error global. En este caso, llámala error de aplicación. Que extienda otras clases de error diferentes que sean más específicas para lo que estás haciendo. Con el fin de tener diferentes capas al manejar tus errores. Una capa es, por ejemplo, una capa de base de datos. Otra es un error que se muestra al usuario, y así sucesivamente. Todas estas tienen casos de error muy específicos. Puedes moldear esas clases de error en módulos separados, de esa manera puedes importar fácilmente el módulo y probarlo contra el error de aplicación.

¡Hola, Liz! ¡Hola de nuevo! Sí, esa fue una charla increíble. Me encantó tu código. Uno simplemente no escribe código sin errores. Sí, eso es totalmente cierto. Sí, así que hiciste la pregunta, el error HTTP 404, ¿es un error operativo o un error de programación, y el 57% de las personas dicen que podría ser ambos. El 28% dice que es un error operativo con un 9% y cambia. Pero sí, el 4%, es un error de programación. Sí, eso es correcto. Si la mayoría de las personas que respondieron a la encuesta tienen razón, porque el 404 puede ser ambos. Por lo general, puede ser un error operativo porque tal vez haya un error tipográfico en la ruta. Por ejemplo, una ruta es la barra diagonal contact y la persona la escribió como slash contacto y eso mostraría un 404, porque no se encuentra. Pero a veces, y menos frecuentemente, también puede ser un error de programación porque el requisito podría decir que la ruta debería ser contact pero el programador crea una ruta diferente por error. Así que la gente tiene razón. Te felicito mucho en esta charla, así que buen trabajo. Sí, hiciste un gran trabajo explicando todos los errores, ¡yay! De acuerdo. Así que echemos un vistazo a algunas preguntas. Entonces, Arzintype1990 pregunta, ¿la infraestructura como código y el enfoque de DevOps difuminan la línea o complican la distinción entre errores operativos y errores de programación? Según lo que he leído al hacer esta investigación y sí, en todas partes es como que siempre habrá dos tipos de errores, como acabamos de ver, o pueden ser ambos, pero siempre hay esta distinción. Así que sí. Sí, siempre habrá una distinción dependiendo del caso de uso. Sí. Sí, dependiendo del caso de uso, y a veces un error puede ser ambos, puede ser, sí.

De acuerdo, sí, depende totalmente del contexto. Espero que hayan obtenido la respuesta a la pregunta. De acuerdo, tenemos otra pregunta. Sí, nuevamente, creo que lo que acabamos de discutir es si un error puede ser tanto un error operativo como un error de programación, o si es uno u otro. Sí. Sí, bueno, sí, a veces tienes tanto errores operativos como errores de programación como parte del mismo problema raíz. Por ejemplo, si el servidor HTTP intenta usar una variable no definida y se bloquea, eso es un error de programación. Y cualquier cliente que solicite en Flags en el momento del bloqueo verá un error, pero normalmente se informa como una interrupción del circuito. Sí, por lo tanto, puede ser básicamente ambos. De acuerdo, bien, y los errores son tan fascinantes.

De acuerdo, tenemos una pregunta, ¿es posible incluir otra declaración entre los bloques try, catch y finally? No, no se recomienda incluir ninguna declaración entre la sección de los bloques try, catch y finally, ya que forman una unidad completa del mecanismo de manejo de excepciones, por lo que no se recomienda, sí, lanzará un error si lo haces. De acuerdo, hablando de estos errores, me preguntaba cuáles son algunos tipos de errores molestos con los que te has encontrado al programar. Sí, por ejemplo, bloquear el bucle de eventos puede ser muy molesto porque podría ser fácil bloquear el bucle de eventos debido a la naturaleza de un solo hilo de Node.js, pero también invocar un callback más de una vez, lo he hecho. Estoy seguro de que mucha gente también lo ha hecho, o esperar que los callbacks se ejecuten de forma sincrónica, parece que no, no, no, o generar errores desde dentro de los callbacks. Esos son errores muy comunes y son muy molestos, es como `oh, lo hice de nuevo`. O el típico error de simplemente olvidar, como un punto y coma o un paréntesis o lo que sea y todo se bloquea. Sí, esos son molestos o supongo que los errores en general pueden ser muy molestos porque a veces es la cosa más simple del mundo y es tan difícil de encontrar y a veces los errores son muy difíciles y simplemente no sabes qué hacer. Así que sí, los errores son una gran parte de la programación y estaba muy emocionado de dar esta charla porque es una gran parte de ella y saber cómo manejar esos errores dependiendo del caso de uso es muy importante. Así que sí, hay diferentes tipos de errores y son muy molestos. Entonces, ¿cuál es tu enfoque, cómo abordas esto? ¿Cómo haces la depuración y cuál es tu enfoque? Hay múltiples formas en las que podemos depurar los errores y todo eso. Bueno, lo primero que siempre hago es simplemente imprimir todo en la consola. Soy un gran fanático de console log. Algunas personas usan otras técnicas como traza asíncrona. Hay sí, hay diferentes técnicas que también se pueden usar como un APM o herramientas externas para la depuración. Sí, pero eso es como una charla completamente diferente sobre cómo depurar aplicaciones. Sí, siempre sigo leyendo todas estas diferentes formas, pero nada supera a console log. Sí, es muy útil. De acuerdo, así que tengo una pregunta de Metin y leí algo esta semana sobre un capturador global de errores, algo así como report error. ¿Viste esta nueva API? ¿Le echaste un vistazo a esta nueva API?