Video Summary and Transcription
Esta charla explora el manejo de errores en Node.js, incluyendo tipos de errores, técnicas de manejo y depuración. Se discute el uso de excepciones, callbacks y promesas para el manejo de errores. Se enfatiza la importancia de un adecuado manejo de errores y los beneficios de usar clases de error, mensajes de error expresivos y pruebas automatizadas. El orador también aborda el uso de TypeScript y el desarrollo guiado por pruebas para la prevención de errores. En general, la charla proporciona valiosos conocimientos y técnicas para dominar el manejo de errores en Node.js.
1. Introducción al manejo de errores en Node.js
Hoy hablaré sobre cómo dominar el manejo de errores en Node.js. El manejo de errores siempre debe ser tomado en consideración al programar. Exploraremos los tipos de errores, cómo manejarlos y patrones para mejorar el manejo de errores.
Hola a todos. Soy Liz Fardy, y Jefa de Defensora de Desarrolladores en una empresa realmente genial llamada Fusebit, enfocada en integraciones para desarrolladores. Gracias por asistir a mi charla. Hoy estaré hablando sobre cómo dominar el manejo de errores en Node.js. Este es mi nombre de usuario en Twitter, LizFardy23. Y si quieres crear integraciones increíbles, echa un vistazo a la cuenta de Twitter de Fusebit.io.
El manejo de errores siempre debe ser tomado en consideración 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, quizás notificamos a los usuarios, informamos al equipo, reintentamos? ¿Pero cuántas veces? Porque uno no simplemente escribe un código sin errores. Y eso es un hecho. Entonces, esta es la agenda para esta charla. Primero, vamos a ver los tipos de errores, errores operacionales y errores de programador, porque hay diferentes estrategias para los diferentes tipos de errores. Luego, veremos cómo manejar esos errores. Y finalmente, patrones para mejorar el manejo de errores. Así que, comencemos.
2. Tipos de Errores y Técnicas de Manejo
Una gran parte de la programación es simplemente 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 generales, errores operacionales y errores de programador. Los errores operacionales son problemas en tiempo de ejecución experimentados por un código bien escrito. Hay cinco técnicas principales para manejar errores operacionales. Primero, reintente la operación.
Una gran parte de la programación es simplemente encontrar y solucionar errores, por lo que es importante hacerlo como un profesional. A veces, al intentar solucionar un error, creamos tres más. O incluso, rompemos toda la aplicación. Entonces, si conocemos las best practices de manejo de errores, es posible reducir el tiempo de debugging, 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 generales, errores operacionales y errores de programador. Los errores operacionales son problemas en tiempo de ejecución experimentados por un código bien escrito. Entonces, el código no tiene problemas, no errores. Estos errores son causados por algo más, algunas circunstancias externas que pueden interrumpir el flujo de la ejecución del programa. Algunos ejemplos son el sistema en sí, 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 cuelgues de sockets, servicio remoto, 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, internet o tu computadora. Es solo un error con el servidor. Falla al conectar con el servidor, tal vez porque no tienes internet. Falla al resolver el nombre de host cuando tienes un error de tipeo en el nombre de host al que estás intentando conectar. Entrada de usuario invá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 inválida proporcionada por el usuario. Solicita una aplicación. Por ejemplo, el servidor tardó demasiado tiempo en responder y falla. Una conexión a la database se pierde, quizás debido a una conexión de red defectuosa. Este es un ejemplo de un sistema que está operando en nuestra memoria, socket colgado, pérdida de conexión a la database, entrada inválida, error 500 o error de servicio remoto, y no WiFi, lo que puede causar falla al conectar con el servidor, error. Cuando experimentas este tipo de errores, no hay mucho código que podamos hacer para solucionarlo. Archivo no encontrado es un error operacional, 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 errores operacionales. Primero, reintenta la operación. Si estás experimentando un error 500 o falla al conectar con el servidor o el servidor está sobrecargado, puedes simplemente esperar y volver a intentar conectar en unos segundos. Las solicitudes de red a un servicio externo a veces pueden fallar, incluso si la solicitud es completamente válida. Tales problemas son normalmente esporádicos, por lo que en lugar de reportarlo o notificarlo, puedes intentar la solicitud unas cuantas 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 buena idea reintentar después de unos segundos o reintentar utilizando la estrategia de retroceso exponencial. Informe el error hasta la pila cuando una función no tiene suficiente información para manejar el error directamente. Notifique al cliente sobre la entrada de usuario inválida y valide la entrada antes de enviarla al usuario. Abortar el programa en casos de errores de sistema irrecuperables. A veces, no hay nada que puedas hacer acerca de los errores operacionales. Los errores de programador son errores en el programa que pueden ser corregidos por el código. Hay seis tipos de errores en JavaScript, incluyendo 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 utilizando la estrategia de retroceso exponencial, que consiste en retrasar el reintento de seguimiento y aumentar progresivamente el retraso para cada reintento consecutivo. El segundo es reportar 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 sin terminar e informar el error a la pila para que pueda ser manejado adecuadamente. Esto es útil cuando una función no tiene suficiente información para manejar el error directamente.
El tercero, notificar al cliente. Por ejemplo, si el error es causado por una entrada de usuario inválida, como una dirección de correo electrónico incorrecta, debes informar al cliente y asegurarte de incluir la información que necesitas para construir el mensaje de error que tenga sentido para el usuario, como dirección de correo electrónico inválida. Al tratar con la entrada externa de los usuarios, siempre asume que la entrada es mala por defecto. Valida la entrada antes de que sea enviada al usuario para que puedan abordarlo antes de iniciar cualquier proceso de manejo de errores.
El siguiente es abortar el programa. Otra solución es simplemente abortar la operación. En casos de errores de sistema irrecuperables, lo único que podemos hacer es registrar el error y terminar el programa inmediatamente. 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 acerca de el error operacional. No hay nada que reintentar o abortar. No hay razón para que el programa se caiga. Un ejemplo podría ser si estás haciendo un seguimiento de un grupo de servicios remotos utilizando DNS y uno de esos servicios sale del DNS. No hay nada que puedas hacer al respecto excepto registrar un mensaje y proceder con los servicios restantes. El manejo de errores es acerca de lo que falló y por qué. La distinción entre error operacional y errores de programador es importante para averiguar cómo entregar esos errores y manejarlos. Ahora veamos los errores de programador, que son los errores donde los desarrolladores tienen control y pueden ser corregidos por el código. Los errores de programador son simplemente errores en el programa. Estos siempre pueden ser evitados corrigiendo y cambiando el código o la lógica. Hay seis tipos de error que se pueden encontrar en JavaScript. El primero es el error de tipo. Es un error cuando una operación no puede ser realizada porque el valor no es del tipo esperado. Por ejemplo, cuando ves un tipo de propiedad indefinida o pasas una cadena cuando se inspeccionó o se requirió un objeto no es una función. En este caso, la variable del
4. Tipos de Errores en JavaScript y su 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 el error de sintaxis, cuando te falta un paréntesis, 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, callbacks, rechazos de promesas.
el parámetro 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 el error de sintaxis, cuando te falta un paréntesis, un punto y coma o comillas dentro de una cadena. Todos esos son errores de sintaxis y son súper 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, haciendo referencia a la variable número donde esta no ha sido definida.
Esos tres son los más comunes, pero hay otros tres que no son tan comunes, pero es útil conocer. El error de rango es un error que recibes cuando un valor numérico excede el rango permitido. Por ejemplo, si tengo un rango numérico de 10 a 20, los números que comienzan este rango recibirá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 sigue llamándose a sí misma indefinidamente. Error de URI. Sucede cuando las funciones de codificación de URI o de codificación de URI se utilizan de manera incorrecta. URI es identificador de recurso uniforme. Por ejemplo, si quieres decodificar signos de porcentaje, lanzará un error de URI. Error de eval. Cuando usas la función eval de una manera incorrecta. Esta excepción ya no es lanzada por JavaScript. Ahora se usa 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 permanece 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 una aplicación está en ejecución. Cómo se informan y manejan estos errores depende totalmente del tipo de error y el estilo de API que se llama. Hay cuatro formas principales de entregar un error en NodeJS. La primera, excepciones. Lanza el error para operaciones sincrónicas. Callbacks, pasa el error a un callback. Una función proporciona específicamente para manejar errores y el resultado de operaciones asincrónicas. Rechazos de promesas, pasa el error a una función de promesa rechazada usando async await.
5. Excepciones y Lanzamiento de Errores
Las excepciones o el lanzamiento del error es una forma común de entregar errores desde funciones. Todos los errores de script JS son excepciones que generan y lanzan un error inmediatamente utilizando el mecanismo estándar de lanzamiento de JavaScript. Cuando lanzas un error, se convierte en una excepción y necesita ser capturado 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 lanzamiento del error que es una forma muy común de las funciones para entregar errores. Todos los errores de script JS son excepciones que generan y lanzan un error inmediatamente utilizando el mecanismo estándar de lanzamiento de JavaScript . Cuando lanzas un error se convierte en una excepción y necesita ser capturado en algún lugar de la pila utilizando un bloque try catch. Si se permite que el error se propague en la pila sin ser capturado, se convierte en una excepción no capturada que causa que una aplicación salga prematuramente. Como podemos ver en este ejemplo, si no hay un manejador, el proceso no tendrá más opción que salir inmediatamente. Mostraré un error de referencia porque z no está definido. Lanzar entrega un error de forma sincrónica, es decir, en el mismo contexto donde se llamó a la función. Si el llamador o los llamadores del llamador usan try catch, pueden capturar el error. En ninguno de los
6. Callbacks y Patrón de Callback Primero de Error
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 primero de error en la mayoría de sus métodos asíncronos para asegurar que los errores se comprueban correctamente antes de utilizar los resultados de una operación. Es importante controlar el flujo del contenido de la función de callback comprobando siempre si hay un error antes de intentar acceder al resultado de la operación.
colorea el programa normalmente se bloquea. Callbacks. La segunda forma de manejar errores es a través de callbacks. Los callbacks son la forma más básica de entregar un error de forma asíncrona y debido a la naturaleza síncrona de Node.js los callbacks se utilizan mucho. Una función de callback se procesa como un argumento para otra función y se ejecuta cuando la función ha terminado. Si has estado trabajando con JavaScript durante un tiempo probablemente has visto el callback mucho. Node.js utiliza el patrón de callback primero de error en la mayoría de sus métodos asíncronos para asegurar que los errores se comprueban correctamente antes de utilizar los resultados de una operación.
Esta función de callback es normalmente el último argumento para una función que inicia una operación asíncrona. Por ejemplo, el método real fight aquí espera una función de callback como su último argumento y se llama una vez cuando ocurre un error como resultado está disponible de la operación, por ejemplo aquí al final en el console log. 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 comprobando siempre si hay un error antes de intentar acceder al resultado de la operación. Ignorar los errores es inseguro y no deberías confiar en el contenido del resultado
7. Uso de Callbacks para el Manejo de Errores
Este es un ejemplo de cómo usar callbacks para lanzar un error de tipo. Cualquier llamador de la función square aquí necesitará pasar una función de callback para acceder a sus resultados o error. Tenga en cuenta que la excepción en tiempo de ejecución ocurrirá si el argumento de callback no es una función. Además, queremos evitar a toda costa el infierno de los callbacks. Un callback, en lugar de un callback, en lugar de múltiples declaraciones de captura puede ser muy complicado. 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 comprobar 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í necesitará pasar una función de callback para acceder a sus resultados o error. Tenga en cuenta que la excepción en tiempo de ejecución ocurrirá si el argumento de callback no es una función.
Además, queremos evitar a toda costa el infierno de los callbacks. Un callback, en lugar de un callback, en lugar de múltiples declaraciones de captura puede ser muy complicado. 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
8. Rechazo de Promesa y 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 utilizas callbacks para el manejo de errores Async.error, pueden convertirse en promesas utilizando el método incorporado utPromiseify. Esta es una forma predominante de usar promesas en un JavaScript moderno porque el código se lee como código asíncrono y la familiaridad del mecanismo try-catch puede utilizarse para manejar errores.
de manejo de errores. Rechazo de promesa utilizando 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 utilizas callbacks para el manejo de errores Async.error, pueden convertirse en promesas utilizando el método incorporado utPromiseify. Por ejemplo, aquí se muestra cómo el método FsReadFile puede ser adaptado para utilizar promesas. La variable readFile es una versión Promisify de FsReadFile en la que las proyecciones de promesa se utilizan para informar de errores. Estos errores pueden ser capturados cambiando los métodos catch como se muestra por ejemplo aquí. También puedes utilizar la API de Promisify en una función Async como en este ejemplo. Esta es una forma predominante de usar promesas en un JavaScript moderno porque el código se lee como código asíncrono y la familiaridad del mecanismo try-catch puede utilizarse para manejar errores. Es importante utilizar un wait antes del método asíncrono para que la promesa se resuelva, se cumpla o se 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 es posteriormente capturado por el entorno circundante
9. Utilizando Promesas y Clases de Error
Puedes utilizar promesas en una función asíncrona devolviendo una promesa de 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 masterclass, 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, llama error de aplicación.
bloque de parche. Puedes utilizar promesas en una función asíncrona devolviendo una promesa de la función y colocando el código de la función en los callbacks de la promesa. Si hay un error, rechaza con un objeto de error. De lo contrario, resuelve aquí la promesa con el resultado para que pueda ser accesible en la cadena. Luego, el método agrega directamente el valor de la función asíncrona cuando se utiliza async await. Finalmente, emisores de eventos. Para casos más complicados, la función en sí 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 de la función y emite el evento tanto para casos de éxito como de fracaso. Un ejemplo de este código se muestra aquí. La función emitCount() devuelve un nuevo emisor de eventos que informa tanto de los eventos de éxito como de fracaso en la operación asíncrona. La función incrementa la variable count y emite un éxito cada segundo y un error si el count es divisible por cuatro. Cuando count 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í es cómo puedes escuchar y React a cada evento emitido desde la función emitCount(). Como puedes ver aquí, la función callback de cada listener de eventos 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 listener para él, el Node.js se bloqueará. Esto es lo que sucede cuando no pones el listener del evento de error y ejecutas el programa. Simplemente se bloquea. En su mayor parte, podemos unir callbacks y emisores de eventos en el mismo cubo de entrega de errores asíncronos. Si quieres entregar un error de forma asíncrona, generalmente quieres usar uno de los otros callbacks o el emisor de eventos, pero no ambos.
Finalmente, la última sesión de esta masterclass, 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, llama error de aplicación. Que se extiende a otras diferentes clases de error que son más específicas para lo que estás haciendo. Con el fin de tener diferentes capas cuando manejas tus errores. Una capa es, por ejemplo, una capa de base de datos. Otra es el error orientado al usuario y así sucesivamente. Todos estos 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 probar contra el error de aplicación.
10. Técnicas de Manejo de Errores
El segundo botón es hacer que los mensajes de error sean lo más expresivos posible. Devolver códigos y estados de error adecuados. El siguiente es YouTube promisify. Algunos proyectos solo admiten callbacks en lugar de un sync wait y no es posible refactorizarlo. El siguiente es adoptar TypeScript. TypeScript es un superconjunto fuertemente tipado de JavaScript. El siguiente es stack traces. Se recomienda encarecidamente utilizar tanto sync weight como sea posible. Número seis, pruebas automatizadas. La presencia de pruebas automatizadas hace que sea mucho más probable que encuentres y corrijas varios errores de programación. Finalmente, debes saber que en JavaScript y Node.js, hay una diferencia entre un error y una excepción.
Cualquier otra cosa serán errores inesperados. El segundo botón es hacer que los mensajes de error sean lo más expresivos posible. Devolver códigos y estados de error adecuados. Si es 500 o 104 y simplemente hacer que los errores sean muy descriptivos. El siguiente es YouTube promisify. Algunos proyectos solo admiten callbacks en lugar de un sync wait y no es posible refactorizarlo. Por lo tanto, puedes usar promisify porque es muy útil para este caso.
El siguiente es adoptar TypeScript. TypeScript es un superconjunto fuertemente tipado de JavaScript. Su principal objetivo de design es identificar construcciones que probablemente sean 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 la base de código de Airbnb se podrían prevenir con TypeScript. Cuando migras todos tus proyectos a TypeScript errores como undefined is not a function o syntax error o reference errors ya no deberían existir en tu base de código. Migrar toda tu aplicación Node.js a TypeScript se puede hacer de manera incremental. Así puedes empezar a obtener las recompensas inmediatamente en partes cruciales de la base de código.
El siguiente es stack traces. Un stack trace es una lista de llamadas a métodos que la aplicación estaba en medio de procesar cuando se lanzó la excepción. Tienes toda la información de dónde esperaste tus promesas. Se recomienda encarecidamente utilizar tanto sync weight como sea posible. Si no lo haces, perderás valiosa información de debugging.
Número seis, pruebas automatizadas. El lenguaje JavaScript no hace mucho para ayudarte a encontrar los errores en la lógica de tu programa. Por lo tanto, tienes que ejecutar el programa para determinar si funciona como sospechaste. La presencia de pruebas automatizadas hace que sea mucho más probable que encuentres y corrijas varios errores de programación, especialmente errores de lógica. También son útiles para afirmar cómo una función se construye con valores atípicos. Usar un framework de testing como Jest o Mocha es una buena manera de empezar con las unit testing para las aplicaciones de Node.js.
Finalmente, 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 que podrían ser construidos y luego pasados directamente a otra función o término. Cuando lanzas un error, se convierte
Manejo de Errores y Preguntas y Respuestas
Throw new error, algo que sucedió. Pero también puedes crear un error sin lanzarlo. Call back, new 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 sincrónica. Conclusión, el manejo adecuado de errores es un requisito no negociable si estás apuntando a escribir un buen código y un 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í hay un ejemplo de uso de un error como una excepción. Throw new error, algo que sucedió. Pero también puedes crear un error sin lanzarlo. Call back, new 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 sincrónica. Conclusión, el manejo adecuado de errores es un requisito no negociable si estás apuntando a escribir un buen código y un 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í, entonces preguntaste, el error HTTP 404 es operacional o de programación, y el 57% de las personas dice que sería ambos. El 28% dice que es un error operacional con el 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 están en lo correcto, porque 404 puede ser ambos. Usualmente puede ser un error operacional porque tal vez hay un error de tipeo en la ruta. Por ejemplo, una ruta es el slash contact y la persona lo escribió slash contacto y eso mostraría 404, porque no se encuentra. Pero a veces, y menos frecuente, también puede ser un error de programación porque el requerimiento podría decir que la ruta debería ser contact pero el programador crea una ruta diferente por error. Entonces, la gente tiene razón. Tú mucho en esta charla, así que, buen trabajo. Sí, hiciste un gran trabajo explicando todos los errores, yay. Vale. Entonces, echemos un vistazo a algunas preguntas. Entonces, Arzintype1990 pregunta, ¿la infraestructura como código y el enfoque DevOps borra la línea o complica la distinción entre errores operacionales y de programación? Entonces, lo que he leído haciendo esta investigación y sí, en todas partes es como siempre va a haber dos tipos de errores, como, a veces los errores pueden ser ambos, como, acabamos de ver, o pueden ser ambos, pero siempre hay esta distinción. Entonces, sí. Entonces sí, siempre habrá 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 operacionales como de programador. No se recomienda incluir declaraciones entre los 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 los puntos y comas o los paréntesis. La depuración de errores se puede realizar utilizando técnicas como console log, async trace y herramientas externas. Hay una nueva API llamada report error que aún no he visto.
Bueno, entonces, sí, depende totalmente del contexto. Espero que hayan respondido a la pregunta. Bueno, tenemos otra pregunta. Sí, de nuevo, creo que eso es lo que acabamos de discutir es ¿puede un error ser tanto operacional como de programador, o es uno u otro? Entonces, sí. Sí. Bueno, sí, a veces tienes errores operacionales y de programación como parte del mismo problema raíz. Por ejemplo, si un servidor HTTP intenta usar una variable indefinida, y se bloquea, eso es un error de programador. Y cualquier cliente que solicite en Flags en el momento de el bloqueo verá un error, pero normalmente se informa como un cuelgue de circuito. Sí, entonces puede ser básicamente puede ser ambos. Bueno, bien, los errores son tan fascinantes.
Entonces, tenemos una pregunta, ¿es posible mantener otra declaración entre los bloques try, catch y finally? No, no se recomienda incluir ninguna declaración entre la sección de try y 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 haces eso. Bueno, hablando de estos errores, me estaba preguntando qué tipos de digamos errores molestos te has encontrado mientras codificas? Sí, por ejemplo, bloquear el bucle de eventos puede ser super 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 lo ha hecho también, o esperar que los callbacks se ejecuten de forma sincrónica, parece que no, no, no, o errores de unión desde dentro de los callbacks. Esos son errores que son muy comunes y son muy molestos y es como oh, hice esto de nuevo. O el error típico de simplemente olvidar, como un punto y coma o como un paréntesis o lo que sea y todo se bloquea. Sí, esos son molestos o supongo los errores en general pueden ser super molestos porque a veces es como la cosa más simple de todas y es simplemente tan difícil de encontrar y a veces sus errores son super difíciles y simplemente no sabes qué hacer. Entonces 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 uso del caso es muy importante. Entonces quiero decir sí. Entonces hay estos diferentes tipos de errores y son super molestos. Entonces, ¿cuál es tu enfoque, cómo los abordas? ¿Cómo haces el debug y cuál es tu enfoque? Hay varias formas en las que podemos debug los errores y todo. Bueno, lo primero que siempre hago es simplemente hacer un console log de todo. Soy un gran fan de console log. Algunas personas simplemente hay otras técnicas como async trace. Hay sí, hay diferentes técnicas que también puedes usar como un APM o herramientas externas para debugging. Sí, pero hay como una charla completamente nueva sobre cómo debug las aplicaciones. Sí, siempre sigo leyendo todas estas diferentes formas pero console log nada supera a console log. Sí. Es super útil. Bueno, entonces tengo una pregunta de Metin y leí algo esta semana sobre un capturador de errores global algo 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 los errores y pregunta sobre sus errores menos favoritos o más memorables. También discuten el tiempo dedicado a la depuración y los beneficios de tomar descansos. Luego, el orador aborda una pregunta sobre TypeScript versus desarrollo guiado por pruebas, expresando su preferencia por usar ambos. También mencionan su aversión 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 acerca de esta nueva API. Gracias. Sí. Así que eso es interesante, un capturador global de errores, sí. Bueno, cuéntanos algo. ¿Hay algo que te gustaría elaborar más en tu charla? Diste una charla muy buena. Entonces, ¿hay algún punto que te gustaría elaborar más que te gustaría. Sí. Sí. Sí. Me gustaría que la audiencia, si pueden, simplemente en el canal de preguntas y respuestas, si pueden decirme cuáles son los errores y qué errores tienen. ¿Cuáles son los errores menos favoritos o cuáles fueron 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 puntuar si pueden responder a esas preguntas o sí, así que sí, háganos saber cuáles fueron algunos de sus errores que encontraron y sí, le echaremos un vistazo y hay otra pregunta que es ¿cuál es el mayor tiempo que has dedicado a la debugging de un error y recuerdas que fue peor o mejor de lo esperado? Lo siento, ¿puedes repetirlo? ¿Cuál fue la? Entonces, ¿cuál es el mayor tiempo que has dedicado a la debugging de un error? Bueno, para mí, creo que fue como un día entero. Como no pude descifrarlo, fue hace un tiempo y pasé todo el día pensando en este error. Y luego, como de costumbre, a veces es realmente bueno simplemente desconectar completamente. Y acostarse o pesar o salir a caminar o cualquier cosa y luego volver y puedes realmente resolver el error como por arte de magia porque tal vez vienes con un enfoque diferente o tienes una mentalidad diferente. Así que a veces cuando estás atrapado en un error y simplemente intentas e intentas, es como si estuvieras en un bucle, se vuelve más difícil. Así que a veces desconectar puede ser extraño que tal vez no debería incluir eso en mi próxima charla. Como desconectar también es una forma de manejo de errores. Sí, sí, sí, a veces cuando ves con ojos frescos de nuevo y luego puedes tener de repente ese momento sí, este era el área. Sí. A veces, no sé si te ha pasado, pero a veces incluso antes, cuando estaba programando mucho, ahora soy desarrollador de relaciones, así que hago menos programación. Incluso podría soñar con programar y es como si resolviera los errores cuando estaba durmiendo y es 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 eso es a lo que te refieres con tdd. Sí, quiero decir, no hay una gran diferencia. Quiero decir, son dos cosas diferentes. Uno es TypeScript, que es lo que he dicho antes, y el desarrollo guiado por pruebas es solo que cubre el caso de prueba antes de que el software esté completamente implementado. 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 algunos casos de uso diferentes y deberíamos estar usándolos a ambos tal vez para tener menos errores. Me gustaría saber qué tipo de errores ¿cuál es tu menos favorito o tu error más memorable? Odio el tipo de errores en los que era muy fácil, justo a mi lado y no podía verlo. Quiero decir, estoy debugging todo el asunto, yendo profundamente en el código como y analizando muchas cosas sí, esto, eso, ya sabes todas las cosas grandes y luego resulta ser ese único problema de bucle o algo así un problema muy pequeño, solo un cambio de línea o un cambio de palabra y ya está. Así que una vez que recuerdo que tuve este problema muy peculiar con la concatenación de matrices y todo, así que como estos siempre son super confusos, 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 se va totalmente al traste. Sí sí, vale, 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 todavía puede continuar la conversación con Liz, vayan al chat especial y únanse a la sala de la oradora y todavía pueden hablar con ella. Gracias Liz por unirte a nosotros de nuevo, adiós, gracias, nos vemos en el otro lado.
Comments