1. Introducción a la gestión de errores en Node.js
Hoy hablaré sobre cómo dominar la gestión de errores en Node.js. La gestión de errores siempre debe tenerse en cuenta al programar. Exploraremos los tipos de errores, cómo manejarlos y los patrones para mejorar la gestión de errores.
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.
2. Tipos de Errores y Técnicas de Manejo
Una gran parte de la programación consiste en encontrar y solucionar errores, por lo que es importante hacerlo como un profesional. 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. Hay cinco técnicas principales para manejar los errores operativos. Primero, reintentar la operación.
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
3. Técnicas de Manejo de Errores y Errores de Programador
Si el código de estado HTTP es 500, 503 o 429, es una buena idea reintentar después de unos segundos o reintentar usando la estrategia de retroceso exponencial. Informa el error hasta la pila cuando una función no tiene suficiente información para manejar el error directamente. Notifica al cliente sobre una entrada de usuario no válida y valida la entrada antes de enviarla al usuario. Aborta el programa en casos de errores del sistema irreparables. A veces, no hay nada que puedas hacer acerca de los errores operativos. Los errores de programador son errores en el programa que se pueden solucionar con código. Hay seis tipos de errores en JavaScript, incluidos los errores de tipo.
alcanza la cantidad máxima de reintentos. Si el código de estado HTTP es 500, 503 o 429, es una buena idea reintentar después de unos segundos o reintentar usando la estrategia de retroceso exponencial, que consiste en retrasar el siguiente reintentar e incrementar progresivamente el retraso para cada reintentar consecutivo. El segundo es informar el error hasta la pila. En muchos casos, es una buena práctica detener el flujo con la ejecución del programa, limpiar cualquier proceso no finalizado e informar el error a la pila para que se pueda manejar adecuadamente. Esto es útil cuando una función no tiene suficiente información para manejar el error directamente.
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
4. Tipos de Errores en JavaScript y Manejo
También puedes obtener este error al intentar modificar un valor que no se puede cambiar o usar un valor de manera inapropiada. El segundo es un error de sintaxis, cuando falta un punto y coma o comillas dentro de una cadena. El error de referencia ocurre cuando haces referencia o llamas a una variable u objeto que no existe o está fuera del alcance del código en ejecución. Hay otros tres errores menos comunes: error de rango, error de URI y error de eval. NodeJS proporciona cuatro formas principales de manejar errores: excepciones, devoluciones de llamada y rechazos de promesas.
no es un tipo válido. También puedes obtener este error al intentar modificar un valor que no se puede cambiar o usar un valor de manera inapropiada. El segundo es un error de sintaxis, cuando falta un punto y coma o comillas dentro de una cadena. Todos estos son errores de sintaxis y son muy molestos. A veces son tan difíciles de encontrar porque la sintaxis del código es incorrecta. El siguiente es el error de referencia. Cuando haces referencia o llamas a una variable u objeto que no existe o está fuera del alcance del código en ejecución. Por ejemplo, hacer referencia a la variable número cuando no se ha definido.
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.
5. Exceptions and Throwing Errors
Las excepciones o lanzar el error es una forma 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.
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
6. Callbacks and Error First Callback Pattern
Los callbacks son la forma más básica de entregar un error de forma asíncrona en Node.js. Node.js utiliza el patrón de callback con el error primero en la mayoría de sus métodos asíncronos para asegurarse de que los errores se verifiquen correctamente antes de utilizar los resultados de una 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.
colors el programa generalmente se bloquea. Los callbacks. La segunda forma de manejar errores son los callbacks. Los callbacks son la forma más básica de entregar un error de forma asíncrona y debido a la naturaleza sincrónica de los callbacks de
Node.js, se utilizan ampliamente. Una función de callback se procesa como un argumento de otra función y se ejecuta cuando la función ha finalizado. Si has estado trabajando con
JavaScript durante un tiempo, probablemente hayas visto el callback muchas veces.
Node.js utiliza el patrón de callback con el error primero en la mayoría de sus métodos asíncronos para asegurarse de que los errores se verifiquen correctamente antes de utilizar los resultados de una operación.
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
7. Using Callbacks for Error Handling
Este es un ejemplo de cómo usar callbacks para lanzar un error de tipo. Cualquier llamador de la función square aquí deberá pasar una función de callback para acceder a sus resultados o errores. Tenga en cuenta que ocurrirá una excepción en tiempo de ejecución si el argumento de callback no es una función. Además, queremos evitar a toda costa el callback hell. Un callback, en lugar de múltiples declaraciones catch, puede volverse muy confuso. Ahora, los callbacks todavía se utilizan para manejar errores de forma asíncrona, pero están pasados de moda porque desde Node.js v8, la forma más popular de manejar errores de forma asíncrona es Async.away, la tercera forma de manejar errores.
Antes de verificar los errores. Este es un ejemplo de cómo usar callbacks para lanzar un error de tipo. Cualquier llamador de la función square aquí deberá pasar una función de callback para acceder a sus resultados o errores. Tenga en cuenta que ocurrirá una excepción en tiempo de ejecución si el argumento de callback no es una función.
Además, queremos evitar a toda costa el callback hell. Un callback, en lugar de múltiples declaraciones catch, puede volverse muy confuso. Ahora, los callbacks todavía se utilizan para manejar errores de forma asíncrona, pero están pasados de moda porque desde
Node.js v8, la forma más popular de manejar errores de forma asíncrona es Async.away, la tercera forma de manejar errores.
8. Promise Rejection and Async.Away
Las promesas son la forma moderna de realizar operaciones asíncronas en Node.js. Generalmente se prefieren a los callbacks porque este enfoque tiene un mejor flujo que coincide con la forma en que analizamos los programas, especialmente con Async.away. Si utiliza callbacks para el manejo de errores de Async, se pueden convertir en promesas utilizando el método utPromiseify incorporado. Esta es una forma predominante de usar promesas en JavaScript moderno porque el código se lee como código asíncrono y se puede utilizar la familiaridad del mecanismo try-catch para manejar errores.
de manejar errores. Rechazo de promesas usando Async.away. Las promesas son la forma moderna de realizar operaciones asíncronas en
Node.js. Generalmente se prefieren a los callbacks porque este enfoque tiene un mejor flujo que coincide con la forma en que analizamos los programas, especialmente con Async.away. Si utiliza callbacks para el manejo de errores de Async, se pueden convertir en promesas utilizando el método utPromiseify incorporado. Por ejemplo, así es como se puede hacer que el método FsReadFile utilice promesas. La variable readFile es una versión Promisify de FsReadFile en la que se utilizan proyecciones de promesa para informar errores. Estos errores se pueden capturar cambiando los métodos catch como se muestra, por ejemplo, aquí. También puede utilizar la API de Promisify en una función Async como en este ejemplo. Esta es una forma predominante de usar promesas en
JavaScript moderno porque el código se lee como código asíncrono y se puede utilizar la familiaridad del mecanismo try-catch para manejar errores. Es importante usar un await antes del método asíncrono para que la promesa se resuelva, cumpla o rechace antes de que la función reanude su ejecución. Si la promesa se rechaza, la expresión await lanza el valor rechazado que posteriormente se captura por el entorno circundante.
9. Utilizando Promesas y Clases de Error
Puedes utilizar promesas en una función asíncrona devolviendo una promesa desde la función y colocando el código de la función en los callbacks de la promesa. 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.
bloque de código. Puedes utilizar promesas en una función asíncrona devolviendo una promesa desde la función y colocando el código de la función en los callbacks de la promesa. Si hay un error, recházalo con un objeto de error. De lo contrario, resuelve aquí la promesa con el resultado para que pueda ser accesible en la cadena. El método then agrega directamente el valor de la función asíncrona cuando se utiliza async await. Finalmente, los emisores de eventos. Para casos más complicados, la función en sí misma puede devolver un objeto emisor de eventos en lugar de usar un callback, y el llamador esperaría escuchar eventos de error en el emisor. En otras palabras, devuelve un emisor de eventos desde la función y emite el evento tanto para casos de éxito como de fallo. Un ejemplo de este código se muestra aquí. La función emitCount() devuelve un nuevo emisor de eventos que informa tanto eventos de éxito como de fallo en la operación asíncrona. La función incrementa la variable de conteo y emite un éxito cada segundo y un error si el conteo es divisible por cuatro. Cuando el conteo llega a 10, se emite un evento de fin. Este patrón permite la transmisión de resultados a medida que llegan en lugar de esperar hasta que se complete toda la operación.
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.
10. Técnicas de Manejo de Errores
El segundo punto es hacer que los mensajes de error sean lo más expresivos posible. Devuelve códigos y estados de error adecuados. El siguiente punto es promisificar YouTube. Algunos proyectos solo admiten callbacks en lugar de una espera sincrónica y no es posible refactorizarlos. El siguiente punto es adoptar TypeScript. TypeScript es un superset de JavaScript con tipos fuertes. El siguiente punto son las trazas de pila. Se recomienda encarecidamente utilizarlas tanto como sea posible. El número seis es las pruebas automatizadas. La presencia de pruebas automatizadas hace que sea mucho más probable encontrar y solucionar diversos errores de programación. Por último, debes saber que en JavaScript y Node.js hay una diferencia entre un error y una excepción.
Cualquier otra cosa será errores inesperados. El segundo punto es hacer que los mensajes de error sean lo más expresivos posible. Devuelve códigos y estados de error adecuados. Si es 500 o 104, simplemente haz que los errores sean muy descriptivos. El siguiente punto es promisificar YouTube. Algunos proyectos solo admiten callbacks en lugar de una espera sincrónica y no es posible refactorizarlos. Por lo tanto, puedes usar promisify porque es muy útil para este caso.
El siguiente punto es adoptar
TypeScript.
TypeScript es un superset de
JavaScript con tipos fuertes. Su objetivo principal de diseño es identificar construcciones propensas a errores sin ninguna penalización en tiempo de ejecución. Al adoptar
TypeScript en tus proyectos, puedes eliminar toda una clase de errores de programación en tiempo de compilación. Por ejemplo, se estimó que el 38% de los errores en el código de Airbnb se podrían haber evitado con
TypeScript. Cuando migras tus proyectos completos a
TypeScript, errores como 'undefined is not a function' o errores de sintaxis o de referencia ya no deberían existir en tu código. La migración de toda tu aplicación de
Node.js a
TypeScript se puede hacer de forma incremental. Así que puedes comenzar a obtener las ventajas de inmediato en partes cruciales del código.
El siguiente punto son las trazas de pila. Una traza de pila es una lista de llamadas a métodos que la aplicación estaba procesando cuando se produjo la excepción. Tienes toda la información sobre dónde esperaste tus promesas. Se recomienda encarecidamente utilizarlas tanto como sea posible. Si no lo haces, perderás información valiosa para depurar.
El número seis son las pruebas automatizadas. El lenguaje
JavaScript no ayuda mucho a encontrar los errores en la lógica de tu programa. Por lo tanto, debes ejecutar el programa para determinar si funciona como se esperaba. La presencia de pruebas automatizadas hace que sea mucho más probable encontrar y solucionar diversos errores de programación, especialmente errores de lógica. También son útiles para verificar cómo una función se comporta con valores atípicos. Utilizar un marco de pruebas como Jest o Mocha es una buena manera de comenzar con las pruebas unitarias para aplicaciones de
Node.js.
Por último, debes saber que en
JavaScript y
Node.js hay una diferencia entre un error y una excepción. Un error es una instancia de una clase de error. Los errores pueden construirse y luego pasarse directamente a otra función o término. Cuando lanzas un error, se convierte
Manejo de Errores y Preguntas y Respuestas
Lanza un nuevo error, algo que sucedió. Pero también puedes crear un error sin lanzarlo. Llama de vuelta, nuevo error, algo que sucedió. Y esto es mucho más común en Node.js porque la mayoría de los errores son asíncronos. Es muy común necesitar capturar un error de una función síncrona. En conclusión, el manejo adecuado de errores es un requisito innegociable si quieres escribir buen código y software confiable. Al emplear las técnicas descritas en esta charla, podrás manejarlo correctamente. Gracias por ver. ¡Feliz codificación!
una excepción. Aquí tienes un ejemplo de cómo usar un error como una excepción. Lanza un nuevo error, algo que sucedió. Pero también puedes crear un error sin lanzarlo. Llama de vuelta, nuevo error, algo que sucedió. Y esto es mucho más común en
Node.js porque la mayoría de los errores son asíncronos. Es muy común necesitar capturar un error de una función síncrona. En conclusión, el manejo adecuado de errores es un requisito innegociable si quieres escribir buen código y software confiable. Al emplear las técnicas descritas en esta charla, podrás manejarlo correctamente. Gracias por ver. ¡Feliz codificació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í.
Tipos de Errores y Técnicas de Depuración
Los errores pueden ser tanto errores operativos como errores de programación. No se recomienda incluir declaraciones entre bloques try, catch y finally. Los errores molestos incluyen bloquear el bucle de eventos, invocar un callback más de una vez, esperar que los callbacks se ejecuten de forma sincrónica y olvidar puntos y comas o paréntesis. Los errores de depuración se pueden solucionar utilizando técnicas como console log, traza asíncrona y herramientas externas. Hay una nueva API llamada report error que aún no he visto.
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?
Discusión sobre Errores y TypeScript vs TDD
El orador invita a la audiencia a compartir sus experiencias con errores y pregunta sobre sus errores menos favoritos o más memorables. También se discute el tiempo dedicado a la depuración y los beneficios de tomar descansos. El orador luego aborda una pregunta sobre TypeScript versus desarrollo guiado por pruebas, expresando su preferencia por usar ambos. También mencionan su desagrado por los errores que son fáciles de pasar por alto pero causan problemas significativos.
No, en realidad no lo vi. Debería echarle un vistazo. Gracias, Metin. Ahora todos sabemos sobre su nueva API. Gracias. Sí, eso es interesante, un capturador global de errores, sí. De acuerdo, cuéntanos algo. ¿Hay algo en lo que te gustaría profundizar más en tu charla? Diste una charla muy buena. ¿Hay algún punto en el que te gustaría profundizar y me gustaría? Sí. Sí. Sí. Me gustaría que la audiencia, si pueden en el canal de preguntas y respuestas, me digan los errores y qué errores tienen. Cuáles son los errores menos favoritos o los errores más fáciles para ellos o los más difíciles me gustaría leer sus enfoques o nunca decir que pueden, si pueden responder esas preguntas o sí, así que sí, háganos saber cuáles fueron algunos de sus errores que encontraron y sí, echaremos un vistazo y hay otra pregunta que es cuál es el tiempo que has pasado depurando un error y ¿recuerdas si fue peor o mejor de lo esperado? Perdón, ¿puedes repetirlo? ¿Cuál fue? Entonces, ¿cuánto tiempo has pasado depurando un error? De acuerdo, de acuerdo. Para mí, creo que fue todo un día. Como que no podía entenderlo, fue hace un tiempo y pasé todo un día pensando en este error. Y luego, como de costumbre, a veces es realmente bueno desconectar completamente. Y acostarse o pesar o salir a caminar o cualquier cosa y luego regresar y puedes resolver el error como por arte de magia porque tal vez vienes con un enfoque diferente o tienes una mentalidad diferente. Porque a veces, cuando estás atrapado en un error y solo intentas e intentas e intentas, es como, simplemente, en un bucle, se vuelve más difícil. Así que a veces desconectarse puede ser útil, tal vez no debería incluir eso en mi próxima charla. Como desconectar también es una forma de manejar errores, simplemente. Sí, sí, a veces cuando ves con ojos frescos de nuevo y de repente puedes tener ese momento, sí, este era el error. Sí. A veces, no sé si te ha pasado, pero a veces incluso antes, cuando estaba codificando mucho, ahora es como que soy relaciones con desarrolladores, así que hago menos codificación. Incluso podía soñ
ar con codificar y era como si resolviera los errores cuando estaba durmiendo y era como, oh no, pero sí. Creo que Jay Scaars pregunta cuál es tu opinión sobre
TypeScript versus
tdd? Bueno, realmente me gusta
TypeScript. Creo que sí, creo que puede resolver muchos problemas y también el desarrollo guiado por pruebas, supongo que por eso mencionaste
tdd. Sí, quiero decir que no hay una gran diferencia. Quiero decir, son dos temas diferentes. Uno es
TypeScript, que es lo que dije antes, y el desarrollo guiado por pruebas es simplemente cubrir el caso de prueba antes de que el software se implemente por completo. Eso es lo que tenemos,
CI,
CD y todo eso. Así que creo que ambos abordan cosas diferentes, así que los usaría a ambos realmente. Sí, tienen diferentes casos de uso y deberíamos usarlos a ambos, tal vez para tener menos errores. Me gustaría saber qué tipo de errores cuál es tu error menos favorito o el error más memorable? Odio el tipo de errores en los que era muy fácil, como justo en mi vista y no podía verlo. Quiero decir, estaba depurando todo el código, y analizando muchas cosas, sí, todo eso grande, y resulta que era un problema simple, tal vez un problema de bucle único o algo así, y ya está. Así que una vez que recuerdo que tuve este problema muy peculiar con la concatenación de matrices y todo eso, como siempre es súper confuso, algunas de las funciones están devolviendo errores, algunas de ellas están mutando y estás usando una u otra y luego tu resultado está totalmente desviado. Sí sí, de acuerdo, sí, así que eso es todo lo que tenemos y gracias, Liz, una vez más por compartir toda esta información con nosotros y la audiencia aún puede continuar la conversación con Liz, vaya al chat especial y únase a la sala de la oradora Liz y aún puede hablar con ella. Gracias, Liz, por unirte de nuevo. Adiós, gracias, nos vemos en el otro lado.
Node Congress 2022
JSNation 2023
JSNation Live 2021
Remix Conf Europe 2022
React Advanced Conference 2023
Comments