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

En ningún bootcamp dudo que enseñen eso

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

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 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-xJ253-u4sXM.html 2. Por qué Raise ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-8WdprhzmQe4.html 3. Either en java ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-1V6WqJfs0C4.html

@@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

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

@@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..

@@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"

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

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 😊

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

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