Por qué no uso Excepciones genéricas en mi código

La manera más común de controlar los errores es utilizar Exception. Pero esto tiene diversos problemas. En el vídeo de hoy lo analizamos.
Curso → cdly.to/curso-...
﹤🍍﹥ Codely
├ 🎥 Suscríbete: kzbin.info...
├ 🔖 Cursos: bit.ly/cursos-...
└ 👋 Redes sociales:
├ / codelytv
├ / javiercane
├ / rafaoe
├ / codelytv
└ / codelytv

[@lsolano2707]

Excelente, ultimamente estan sacando unos super cursos pequeños pero sustanciosos, sigan asi

[@nolascomedina9545]

Muy buen video! Justamente, siempre he encontrado que el manejo de excepciones es un lío. Ahora con esto, se me ocurren algunas cosas que puedo hacer, muchas gracias!

[@Jhonmundo]

Es muy util tener excepciones personalizadas, sobre todo si hereden de un tipo en en especifico que pueda manejar en la capa de infraestructura para poder atraparlas y generar una respuesta automaticamente del tipo 400 - BAD REQUEST para las APIs REST.

[@jonathanhernandez-kv4ck]

Las excepciones personalizadas me parece excelente, pero por experiencia para tener una trazabilidad más completa es necesario agregar códigos de error para tu exception, y así evitas crear cincuenta mil exceptions.

[@hba6018]

Codely esta a otro nivel.

[@edwineinsen]

Una consulta, también puedo utilizar el patrón "Cadena de Responsabilidad" (Chain of Responsibility) ya que casualmente donde trabajo hicieron una demo de este, y me pareció excelente para el manejo de excepciones, ya que permite desacoplar el emisor de la excepción (el código que la lanza) del receptor (el código que la maneja). Crear una cadena de manejadores, puesto que cada manejador tiene la oportunidad de procesar la excepción. Si un manejador no puede manejarla, la pasa al siguiente en la cadena. También se pueden agregar o quitar manejadores de la cadena sin afectar a otros componentes del sistema. Qué les parece? P.D. Me gusta mucho lo que comparten, muchas gracias.

[@carlosestebangil]

muy claro este video, sigan asi a este nivel de claridad. muy buen canal

[@juanpablodiazalbarracin7182]

Yo lo uso en Symfony y es muy util

[@Teamview789]

El tema de errores es todo un desarrollo aparte pero creo que sí ya tienes uno se puede usar para otros proyectos verdad?

[@ppdbm7352]

Esto nos lo enseñaron en el bootcamp de MERN stack hace batantes años, muy buena!

[@johanlopeztorres235]

En ningún bootcamp dudo que enseñen eso

[@ppdbm7352]

@@johanlopeztorres235 a nosotros un día nos lo enseñó el profesor, qué quieres que te diga... 🤷

[@caballoloco100]

Buen contenido 👍

[@miguelsalas634]

He escuchado que las excepciones pueden causar problemas de rendimiento que solo se recomiendan en casos donde realmente el codigo se rompe y no en logica de la aplicacion es cierto esto?

[@davidcanadasmazo]

Sí, es cierto, y además significativamente más costoso en aquellos lenguajes que implementan excepciones "de coste cero" como C++, donde el coste de la excepción es cero si no se lanzan, pero extremadamente caras si se lanzan.

[@Thelimbers7]

Esos cursos son súper útiles, es una pena que de momento no me pueda permitir la suscripción :(. Yo aprendí muchas de esas cosas con recursos de internet, blogs, artículos con Result, Either, etc y la verdad fue muy difícil al no tener una guia especializada y aún tengo dudas de los mismos/

[@CodelyTV]

Iremos publicando más vídeos sobre la gestión de errores aquí. 🙌 También tienes estos 3 vídeos/directos que pueden ser interesantes: 1. Por qué Either kzbin.info/www/bejne/rnuVZmZjqpmmjq8 2. Por qué Raise kzbin.info/www/bejne/bojHoaWer9KEm5Y 3. Either en java kzbin.info/www/bejne/Z4eZiKSAm9hjeZY

[@Thelimbers7]

@@CodelyTV Gracias, ya me miré esos videos, la calidad es exepcional como siempre, también los videos de patrones de diseño criteria, clean architecture, solid, modelado del dominio, son todos muy útiles

[@atorancio]

IMPORTANTE!!: Tener buena politica de retrys y usar DLQ, porque (hablo por experiencia) si hay mucha concurrencia y en orquestaciones tenes algun error de estos controlados, puede quebrar el rendimiento de tu app estos objetos! True Story.. jeje

[@victorhugotiradopenaranda3149]

Teniendo en mi API las clases BadRequestException, que extiende de Exception, y luego EmailRequiredException, que extiende de BadRequestException, ¿es recomendable delegar a BadRequestException la tarea de emitir el response de estado 400 al cliente? Sabiendo que este tipo de errores serán manejados por esta excepción, sería cómodo delegarle esta tarea, pero no sé si en realidad sea recomendable, ya que esa no es la esencia de una excepción.

[@Deus-lo-Vuilt]

Buenísimo vídeo ❤

[@barrenaedu]

Keep It Simple (KISS), no estoy de acuerdo con lo que dicen. Si las excepciones se usan solo para logear, crear excepciones personalizadas para cada validación posible no tiene ningún sentido, se sale de control, se crean excepciones repetidas, etc.., es mejor usa la exception generica Exception (porque siempre se loguea el stack trace y sabemos de donde viene el error). Para crear excepciones personalizadas hay tener muy en claro el motivo, y no tiene que pasar por un simple logueo.

[@bagocavs]

testear casos de usos complejos con excepciones genericas es un dolor de huevos, al personalizar cada excepcion se simplifica el testing mucho, me sorprendio que no mencionaran eso, me parece uno de los mayores beneficios

[@barrenaedu]

@@bagocavs comprendo tu punto de vista, pero codificar pensando en el testing no sería tampoco adecuado, el coding debería ser agnostico al testing. Porque si se entra en ese terreno las cosas pueden terminar mal, como metodos publicos, etc..

[@bagocavs]

@@barrenaedu comparto lo que decis, pero creo que para el tema de la excepciones vale la pena, me parece que el beneficio que aportan es mayor a su "costo"

[@erickgualpa9770]

La gran ventaja que te puede aportar (y digo puede porque cada caso es único) es tener un control sobre esos escenarios excepcionales de tu aplicación/dominio. Si tienes en el código esa facilidad para controlar esos escenarios tienes una gran flexibilidad a la hora de diseñar tu aplicación en cuánto a como se comporta durante los "sad-paths". El objetivo no es el logging, es la centralización (o encapsulación) de está lógica en el dominio. Ejemplo muy básico: La validación de un filtro de rango de fechas, pudiéndose lanzar una excepción tipo InvalidDateRangeFilter o incluso DateRangeIsSwapped (dependiendo de lo fino que quiera hilarse). No tienes porque loggear esa excepción, a lo mejor solo quieres mapearla a un 400 si es un controller lo que ejecuta el caso de uso pero de esta forma te aseguras que la excepción se controla desde un único sitio. De otra forma a lo mejor acabarías validando esto previo a ejecutar una query a BBDD o la llamada al servicio de turno (dependiendo de cuál fuese tu implementación), si es que se validase en el mejor de los casos...

Estoy en parte de acuerdo con lo que dices. En mi caso este tipo de excepciones las uso para modelar business rules de mi dominio. Nunca como una simple cláusula de guarda. Las mónadas usando result pattern lo dejo para la capa de aplicación

[@plasmodiun1]

Las excepciones son eso algo excepcional por eso deben manejarse como tal y no evitar su uso

[@Sam-hu3xt]

Y en vez de usar try-catch que os parece evaluar todas las precondiciones necesarias para llamar a un método usando un if-else, algo del rollo: if( query_will_succeed( /* params */ ) /* call query branch */ else /* query error branch */ Lo digo para ciertos entornos en los que no esté permitido saltos entre contextos de ejecución.

[@NEKSZER]

Caes en el error de usar clausa de guarda, imagina que tienes 4 exceptions, harias varios if else?

[@Sam-hu3xt]

@@NEKSZER seguramente si, cual es la relación entre usar try-catch y el número de condiciones?

[@NEKSZER]

@@Sam-hu3xt pues es tal cual mi respuesta bro, si haces una evaluación por sobre cada posible error en la ejecución, tendrías bastantes if else, lo que repercute en el número de caminos posibles del programa (complejidad ciclomatica). Lo que conviene de cierta manera, es usar los try catch en partes fundamentales del código donde sabes que pueden pasar mil y una cosa como error. Si no más es uno, usas if else.

[@Sam-hu3xt]

@@NEKSZER Yo lo de enmascarar complejidad ciclomática usando un try-catch no lo veo un buen argumento. Porque siempre va a ser mejor explícito que implícito. Si tienes una excesiva complejidad ciclomática, en mi opinión debes rediseñar tu modelo. No digo que lo que comentas no tenga sus usos. Un saludo.

[@escorpolo]

Combinalo con el patrón de diseño Result

[@signas13]

Por un momento me hicieron dudar de mi mismo y fui corriendo a mi editor a ver si podía extender de la clase Exception. Creo que se confundieron con otro lenguaje.

[@CodelyTV]

Es para mostrar el ejemplo y que la keyword más común en los lenguajes es Exception 🙌 Correcto que en el mundo Js es Error 😊

[@DanielRamos-zx1kh]

Solo un detalle: en JS/TS es new Error, no Exception jaja

[@CodelyTV]

Totalmente! Es para mostrar el uso de la Keyword más usada 🙌

[@pablomarianom]

Primer comentario :)

[@CodelyTV]

Qué velooooz!! Vigila que no sale una excepción por una condición de carrera!!!!

[@danielrosario453]

Yo con Golang en la mochila.

[@BackDoorMann]

Todavía no he visto jamás un caso práctico donde sea posible recuperarse de una excepción. En todos los casos lo que se hace es loggear el error. Para eso no hacen falta complejas jerarquías de excepciones personalizadas.