¡Maneja los errores de JavaScript como un senior!
ฝัง
- เผยแพร่เมื่อ 21 พ.ค. 2023
- Con esta técnica vas a aprender cómo manejar correctamente errores en JavaScript. Crearás tus propios errores y evitarás que los problemas de tu infraestructura lleguen al cliente.
Con estas buenas prácticas vas a mejorar la mantenibilidad y escalabilidad de tu código.
▶ No te pierdas más directos en: / midudev - วิทยาศาสตร์และเทคโนโลยี
Midu, cada que tengo una inquietud sobre cómo manejar los errores regreso a este video y no tienes idea como me aclara el camino. Gracias por ser tan genial y aportar tanto a mi vida!
Muchas gracias en serio por tu contenido midu, después de verlo he mejorado considerablemente en las practicas que aplico en mi trabajo y gracias a ti estoy tratando de buscar un trabajo como React dev. En serio, muchas muchas gracias!!!
Qué genial, Edwin!
Miduu deberias hacer una sección de buenas prácticas, saludos
Saludos!! Cada vez con vos aprendo un Mundo y mas horita que estoy asiendo mi primera app Web :D
Muy buen video, muchos de los conceptos que mostraste es como se trabaja en C#, el manejo de errores, patron factory..
En verdad excelente, gracias por compartir 👍
Casualidad hace unas horas estaba pensando de como se deberia resolver los errores, gracias midu por los conocimientos!
Gracias midu por el video, muy interesante, un saludo!
Gracias midu, de tí he aprendido a mejorar mucho mi código!. Algún libro que recomiendes para aprender este tipo de cosas?
no manches el video esta muy informativo gracias midu
En nuestro caso utilizamos hapi/boom para el manejo de errores en node + expressjs para la mayoría de los casos, pero no sabría si esta forma de manejarlos sería una mejor opción 🤔a pesar que pinta muy bien.
Saludos!
Estos videos son arte de programador
Justo lo que necesitaba.
Creí que tenías 27 realmente jaja, buen video, saludos desde México.
Eso es muy cierto muchos servicios retornan toda la traza del error, una buena practica es tener un middleware que interpreta el error
Suele ser un buen recurso para manejar errores fugitivos, en mi opinión es mejor mantener el código de manejo de errores cerca al código susceptible a esos errores que tener que perseguir las trazas desde un middleware, pero lo que te funcione se vale haha
No se si es mi opinión solamente, y espero que @midudev, lea este mensaje, pero este tema me parece super interesante e importante. Y me gustaria mucho que Midu hablara mas al respecto, en un video mas completo.
Muy buen video. También puedes crear un control de errores más robusto evitando los if else o switch implementando el patrón Either monad con alguna aproximación a pattern matching
Innecesariamente complejo sin justificación, lenguaje equivocado para esa aproximación
Interesante aproximación, lo único que me podría resultar desagradable es lo complicado que se torna dar mantenimiento a las multiples clases en aplicaciones muy grandes, con la aproximación del factory te evitas algunos de esos problemas pero solo si lo usas en runtime para generar los errores dinámicamente on-demand.
Pero pierdes el determinismo..... haha
Quizá es mi aversión a las clases la que habla.
Suelo usar factories de loggers en cada archivo que trazan los errores por archivo y método con un middleware a alto nivel para evitar propagarlos a cliente, me resulta simple y suele ser fácil de aplicar (solo usen el logger y ya), pero claro eso ya es un tema distinto....
También es bueno agregarle la propiedad cause, para saber que fue lo que realmente causó el error. Saludos.
Totalmente. Creo que lo comentamos en el vídeo. O igual lo hicimos en el directo, pero lo corté en la edición.
Qué editor de código usaste en este video? me da un aire a visual studio code bastante minimalista.
Nombraste el this y termino el video. Lo cortaste antes de que se vaya la gente 😂😂😂
Jajajaja el this de la muerte
min 7 Si despues del setTimeout llamas a validateUser ya dejas de hacer un try-catch n¿
Un return a una funcion que vuelva hacer el try-catch no seria mejor? es cómo suelo hacerlo.
como seguir controlando los stacks del error? muchas gracias!
@midulive speaking of react, is it possible to handle this using only useErrorBoundary? thank u
Que cómodo es esto en java que puedes indicar que errores puede lanzar el método y el cliente sabe que necesita un capturarlo, a ver si llega algo así a TS
Hola Midu! Me quedé con la parte de prototypes, ¿dónde puedo aprender eso? Huele a algo muy a bajo nivel del lenguaje y me da curiosidad para realmente entender lo que pasa por detrás. Me sorprendió que las clases sean syntactic sugar!
Busca contenido sobre prototype inheritance en JS, en efecto es un tema de bajo nivel.
Buena noche a todos, super el video!
Tengo una duda fuera del video:
Es bueno que a los desarrolladores se nos mida por horas de tiempo trabajadas?
En mi opinión se nos debería medir como desarrolladores sobre el valor agregado que le damos a un cliente, más no al tiempo en que estamos detrás de una computadora
Les comento: actualmente estoy en una empresa en donde los desarrolladores tenemos que registrar diariamente un tiempo determinado sobre las tareas o proyectos que tengamos asignados. Cada que llega un nuevo requerimiento se estima en horas cuanto puede durar ese requerimiento y eso se le asigna al requerimiento o tarea, el desarrollador tiene un tiempo determinado para sus labores y así se va el día a día, sin embargo hay tareas que son complejas para algunas personas. Para mi es facil ya que llevo 2 años en la empresa y lo que me asignan me toma poco tiempo en resolverlo porque ya sé donde buscar la info y demás, pero en su momento me tomó tiempo adaptarme y me tocaba estar muucho tiempo fuera de mi horario laboral resolviendo problemas del mismo desarrollo y son bastante tacaños por así decirse a la hora de brindar más tiempo. De igual forma eso hacía que me llenara de requerimientos y requerimientos sin finalizar ya que no tenía donde registrar mis horas trabajadas ya que tenía que investigar mucho, ahora mismo eso lo estan viviendo los desarrolladores nuevos que entran a la empresa y estoy pensando en proponer otro mecanismo o indicador que nos mida como desarrolladores
1. Estimar en función de quien va a tomar la tarea
2. Tener una tarea previa de análisis que baje la incertidumbre de la tarea compleja
3. Documentar tu conocimiento ante consultas frecuentes, dijiste que a vos hay cosas que te son más fáciles por saber dónde buscar, compartir esa sabiduría para que los más nuevos no pasen por lo mismo que te disgustaba cuando estabas en su posición.
Fuera de eso, estoy de acuerdo en que se debería tomar el valor en base a objetivos y no a tiempos, pero eso es más un cambio cultural de la empresa, que es más difícil de moldear.
Añadir sobre la modificación de prototype: con que coincidieran modificaciones del mismo prototipo en dos librerías diferentes en un proyecto sería muy fácil que hubiera un conflicto entre ambas.Yo solo lo recomendaría en un contexto de aprendizaje, para entender cómo funcionan los prototypes, pero nunca para una aplicación real. Con la extensión, al ser tipos creados en sus respectivas librerías, este problema no existiría.
Hay forma de crear un handler generico para todas las peticiones a un microservicio construido con express? algo asi como un filter en spring cloud gateway?
lo pregunto, para no tener que estar usando try{}catch(){} en cada funcion, si no mas bien tener una clase generica que captura todo error que suceda en la aplicacion
Justo lo que necesitaba, gracias master midu!, como se llama el ide en el que trabajas y te muestra la respuesta enseguida?. gracias.
Run js
cual es ese editor ?
Yo he visto mucho con la gente de Codely sobre utilizar Either para que el cliente que utiliza la función sepa que puede fallar y de qué formas, qué opinas acerca de eso? 🤔
overkill, basicamente es construir una maquina de estado finita determinista completa solo para el manejo de errores, prácticamente no ofrece valor alguno a una aplicación a MENOS que necesites que sea ridiculamente robusta, como.... un core bancario o algo similar.
Y si buscas esa clase de estabilidad, JS es el lenguaje equivocado 1000%
@@Fernando-ry5qt Bueno, tal vez en js sí puede que no tenga mucho sentido, pero utilizando Typescript como una forma de mostrar al cliente que utiliza la función que puede fallar, ahí siento que sí aporta, ya que si no, no te enteras de que algo puede fallar hasta que falla y además pienso de una forma más "elegante" que regresar una tupla de valor o error, similar a como lo hace Go
@@oscareduardo9554 Sigo pensando que el costo técnico de aplicar un patrón funcional difícilmente da buenos retornos de inversión.
Es elegante, si, lo es, también correctamente aplicado puede ser muy eficiente y productivo.
Pero intenta explicarle a un Jr que es un Monad sin que le explote la cabeza y luego vemos si consideras que es buena idea basar toda tu arquitectura de manejo de errores en ello.
Si no trabajas con Jrs, más motivos para mudarte a otro lenguaje más apropiado para el propósito, la curva de aprendizaje es considerablemente más simple.
Por otro lado, puedes argumentar si es filosóficamente correcto tratar un "error" como un posible retorno, que es básicamente lo que hace la FP, de ser así, no es mejor tratar los métodos como funciones de multiples retornos? volver a los callbacks estandar de Node quizá? o si ya estamos construyendo una maquina de estados, porqué no llevarlo a toda la app?
Creo que todas estas preguntas son.... prácticamente una perdida de tiempo haha, difícilmente ofrecen un incremento notable de rendimiento o estabilidad que justifique la molestia, la metaprogramación de los peores enemigos de la productividad.
que thema de visual es ese?
❤🎉
En axios se pueden usar los interceptors
No tiene nada que ver una cosa con la otra. Podrías usar interceptors y seguir haciendo lo que usamos en el vídeo. :)
Hola Midu, hablando de el tema de los errores, como puedo generar archivos logs de los errores que se tengan en la página, me han pedido varias veces que los integre pero nunca he dado en como poder hacerlo
si utilizas node con filesystem puedes crear archivos
y ahi puedes mandar los errores en formate json y luego concatenarlos unos con otros
Que editor es ese?
Yo tampoco entendí la diferencia entre extender un prototype y extender una clase 😅
Útil para node. Lo hacen nest
De los errores se aprende
Como se llama ese tema?
En realidad es irrelevante usar clases específicas para los errores. El error lo debes manejar en el sitio donde ocurra. Para los casos en que necesites actualizar la UI es mejor usar eventos o si usas redes hacer un Dispatch.
Ojú, menudo comentario te has marcado.
No necesariamente, hay muchos errores que no son terminales y lo correcto es propagarlos para darles un manejo a mas alto nivel, por ejemplo, un DAO o cualquier conector, sin contexto, no puedes manejarlo.
Cuidado con los absolutos.
@@Fernando-ry5qt bien dicho.
Eres mi padre
Interesatne, pero mi pregunta es ¿Cuál es la extensión que tienes debajo del código corriendo?, pareciera QuokaJS pero se ve que no lo es, gran video.
No es un editor, es un playground, se llama runjs
@@oscareduardo9554 Muchas gracias por la información, lei muchos comentarios hasta que porfin resolviste mi duda existencial jejjejejeje Gracias.
Midu ahi estabas gordito xd
No ombe.el problena es que asi se nos enseña en los tutoriales y en la documentacion de forma mal .😂😂😂
27 años, ya toca escopeta
Te respeto bro, pero en definitiva no eres SR developer
De alguna manera siento resquemor al ver esa imagen de portada del video... es decir, porqué hacer eso?.
Parece un tipo de menosprecio. literalmente. No es la primera vez que lo haces, lo dice alguien que nisiquiera es un junior AUN😂. Eventualmente llegaré a esa etapa y la atravesaré como muchos.... es muy probable que te importe mil ectareas de Ver.g4 mi comentario, pero si te importa quizás cambies un poco eso y quizás obtengas más seguidores... yo que se 🤷🏽♂️.
¿Qué menosprecio le ves a la portada? 🤔 El vídeo va de cómo crear errores como un senior. Es normal que una persona con poca experiencia no sepa hacerlo y para eso es el vídeo, para explicarlo y enseñar.
No seas grave bro. Agradece que está aportando valiosa información.
En lo particular no me gusta mandar validaciones tan sencillas a un handle de errores, eso si me parece de noobs jejej sin ofender, en mi caso prefiero crear un arreglo de errores y validar cada propiedad con un if(!user?.name) listErrors.push("Name required"), al final hago un conteo de los elementos de mi arreglo de errores, de esta forma puedo mostrarle al usuario si quiero los errores o que datos son requeridos, HACERLO SENCILLO ES LO COMPLEJO!! @midulive, si me equivoco me comentas.
Creo que no has entendido el vídeo, directamente. jajaja
Se llama ejemplo😅