Y respecto a cuando usar Excepciones y cuando no, siento que ya es algo opinionated, ya que en un proyecto grande en el que trabajo, así manejamos los flujos, con excepciones personalizadas.
Un filtro, middleware o lo que sea, se encarga de lo excepcional y no excepcional por así decirlo, pero todo son Exceptions.
Por hay he visto que lanzar excepciones puede ser algo más costoso, ya que una excepción genera un stacktrace y más información para esa situaciones excepcionales, por lo que puede llevar a reservar más memoria.
Un objeto Result, simplemente es esa reservación de memoria con los datos que tienes pensado regresar o con el mensaje de error que buscas informar.
Personalmente, no he confirmado si en rendimiento afecta, por lo que al final, siento que el Results Patterns es algo dogmatico que para algunos así debe de ser y para otros les dará igual :) jaja.
@isaacojeda Si afecta muchísimo hacer un throw exception al rendimiento. estamos hablando de muchos milisegundos que se pueden ahorrar si se controlan las excepciones de manera correcta como lo explicas en este artículo. Si tengo conocimiento de que el flujo va a presentar fallas, debo asegurarme de controlarlo en todo momento, si es factible.
@isaacojeda Me encantaría si pudieras dar una charla de este tema en mi canal de YouTube
Puede ser dogmático, así mismo pasa con otros temas como Clean Architecture ó Repository Pattern (muchos lo aplican solo por aplicar).
Sin embargo, últimamente me he dado cuenta, que lo más hermoso del desarrollo de software es filosofar. Cuestionar todo, hasta tus propios conocimientos. Esto ayuda a tomar la decisión correcta cuando toca dar una solución a un problema.
Con respecto a lo otro, lanzar excepciones es costoso, no solo en términos de uso de memoria. Por ejemplo, el runtime debe hacer muchas cosas cuando se genera una excepción como por ejemplo, recorrer la pila de llamadas hasta encontrar un try-catch, así que mientras más profundo sea el stack, más comprobaciones habrá y más trabajo para el runtime.
Es por esa razón que la excepciones fueron diseñadas para ser utilizada en casos excepcionales, que por lo general, ocurren con muy poca frecuencia (es menos crítico para el rendimiento).
Hasta el mismo david fowl dijo que en ASP.NET Core es aún más costoso lanzar excepciones (aún no sé el porque, hay que investigar). :D
Aún así, cada quién hace su proyecto como quiera... haha
PD: Go ha tomado una buena decisión en no incluir excepciones, en cambio en C# abusan de ello.
Hola @mrdave1999;
Esta muy interesante tu comentario.
Y ahora me siente un poco mal XD. Ya que en mis proyectos tengo un Midleware con un TryCatch y uso throw new Exception en todas las validaciones que hago.
No deberías de cambiarlo si no sientes impacto en tu performance, yo tengo un sistema ya muy grande, siempre en crecimiento de usuarios y controlar el flujo por medio de excepciones por ahora no representa un problema en el rendimiento.
Es real que es más costoso que utilizar algo como FluentResults, pero si nos ponemos a medir todo, también es más costoso utilizar MediatR que un servicio inyectado.
Si tienes problemas de rendimiento, investiga la causa origen, y si resultan ser las excepciones, pues sí hay que cambiarlas, de lo contrario, te recomiendo que sigas igual.
@dsegura Sí tienes el tiempo necesario para cambiar tu código e incluso si no tienes un problema de rendimiento, te recomiendo que lo hagas.
¿Por qué? Sí lo dejas así como está, le estarías indicando a los futuros mantenedores de tu código que lanzar excepciones para todos los casos es correcto, cuando en realidad no es así. Además, puede llegar a confundir aquellas personas que tienen claro la definición de exception.
Por ejemplo, mencionas que lanzas excepciones para validaciones de usuario, como verificar sí el email tiene el formato correcto pero en sí esto no representa un comportamiento anormal, por lo que no tiene sentido lanzar una excepción. Es solo un error de un usuario común.
Las excepciones se lanzan cuando sucede algo inesperado (una situación que nunca debió pasar).
De igual manera, es tu decisión.
No me hagas caso, usted mismo llegue a su propia conclusión.
Y respecto a cuando usar Excepciones y cuando no, siento que ya es algo opinionated, ya que en un proyecto grande en el que trabajo, así manejamos los flujos, con excepciones personalizadas.
Un filtro, middleware o lo que sea, se encarga de lo excepcional y no excepcional por así decirlo, pero todo son
Exceptions.Por hay he visto que lanzar excepciones puede ser algo más costoso, ya que una excepción genera un stacktrace y más información para esa situaciones excepcionales, por lo que puede llevar a reservar más memoria.
Un objeto Result, simplemente es esa reservación de memoria con los datos que tienes pensado regresar o con el mensaje de error que buscas informar.
Personalmente, no he confirmado si en rendimiento afecta, por lo que al final, siento que el Results Patterns es algo dogmatico que para algunos así debe de ser y para otros les dará igual :) jaja.
Saludos!
@isaacojeda Si afecta muchísimo hacer un throw exception al rendimiento. estamos hablando de muchos milisegundos que se pueden ahorrar si se controlan las excepciones de manera correcta como lo explicas en este artículo. Si tengo conocimiento de que el flujo va a presentar fallas, debo asegurarme de controlarlo en todo momento, si es factible.
@isaacojeda Me encantaría si pudieras dar una charla de este tema en mi canal de YouTube
Hola @mteheran!
Claro, un placer colaborar en tu canal :)
Nos mensajeamos por twitter si gustas.
Saludos!
Puede ser dogmático, así mismo pasa con otros temas como Clean Architecture ó Repository Pattern (muchos lo aplican solo por aplicar).
Sin embargo, últimamente me he dado cuenta, que lo más hermoso del desarrollo de software es filosofar. Cuestionar todo, hasta tus propios conocimientos. Esto ayuda a tomar la decisión correcta cuando toca dar una solución a un problema.
Con respecto a lo otro, lanzar excepciones es costoso, no solo en términos de uso de memoria. Por ejemplo, el runtime debe hacer muchas cosas cuando se genera una excepción como por ejemplo, recorrer la pila de llamadas hasta encontrar un try-catch, así que mientras más profundo sea el stack, más comprobaciones habrá y más trabajo para el runtime.
Es por esa razón que la excepciones fueron diseñadas para ser utilizada en casos excepcionales, que por lo general, ocurren con muy poca frecuencia (es menos crítico para el rendimiento).
Hasta el mismo david fowl dijo que en ASP.NET Core es aún más costoso lanzar excepciones (aún no sé el porque, hay que investigar). :D
Aún así, cada quién hace su proyecto como quiera... haha
PD: Go ha tomado una buena decisión en no incluir excepciones, en cambio en C# abusan de ello.
Hola @mrdave1999;
Esta muy interesante tu comentario.
Y ahora me siente un poco mal XD. Ya que en mis proyectos tengo un Midleware con un TryCatch y uso
throw new Exceptionen todas las validaciones que hago.Tendré que mejorar esto urgente.
No deberías de cambiarlo si no sientes impacto en tu performance, yo tengo un sistema ya muy grande, siempre en crecimiento de usuarios y controlar el flujo por medio de excepciones por ahora no representa un problema en el rendimiento.
Es real que es más costoso que utilizar algo como FluentResults, pero si nos ponemos a medir todo, también es más costoso utilizar MediatR que un servicio inyectado.
Si tienes problemas de rendimiento, investiga la causa origen, y si resultan ser las excepciones, pues sí hay que cambiarlas, de lo contrario, te recomiendo que sigas igual.
Saludos!
@dsegura Sí tienes el tiempo necesario para cambiar tu código e incluso si no tienes un problema de rendimiento, te recomiendo que lo hagas.
¿Por qué? Sí lo dejas así como está, le estarías indicando a los futuros mantenedores de tu código que lanzar excepciones para todos los casos es correcto, cuando en realidad no es así. Además, puede llegar a confundir aquellas personas que tienen claro la definición de exception.
Por ejemplo, mencionas que lanzas excepciones para validaciones de usuario, como verificar sí el email tiene el formato correcto pero en sí esto no representa un comportamiento anormal, por lo que no tiene sentido lanzar una excepción. Es solo un error de un usuario común.
Las excepciones se lanzan cuando sucede algo inesperado (una situación que nunca debió pasar).
De igual manera, es tu decisión.
No me hagas caso, usted mismo llegue a su propia conclusión.
Saludos.
Si, Intentaré hacerlo poco a poco,
Muchas Gracias Dave, por tu comentario;