#61778 como norma general lo que dice fyn4r es el rule of thumb canónico que se utiliza para explicar esta situación: las excepciones son para situaciones excepcionales. Esto se traduce en no usarlas para controlar el flujo del código. Un ejemplo pueden ser validaciones de dominio como comprobar que un dato es válido (como un email) o que el estado de los datos permiten realizar la operación que se pretende realizar (como un check de permisos).
Desarrollando un poco el rule of thumb y sin meternos en desvaríos de performance, recurrir frecuentemente a excepciones hace el código menos legible porque implica una indirección que no es fácil de seguir:
public User FindUser(Guid guid)
{
if (guid == default) throw new EmptyGuidException("User GUID can't be empty");
return new User(guid: guid);
}
Si necesitas saber cuándo o cómo se gestiona (o si se gestiona siquiera) EmptyGuidException tienes que navegar el callstack a mano. Navegar usando el "go to reference" del editor no te servirá porque se usará en otros cientos de sitios. Tampoco sabes fácilmente si esta excepción es atrapada por un try-catch que use una excepción padre (por ejemplo la clase excepción raíz que en csharp se llama Exception). Esto cuando son 4 funciones no pasa nada pero se hace evidente que no escala bien con la complejidad del código.
Resumen de la jugada: has perdido mucho y no has ganado nada a cambio.
Si lo abordas desde la perspectiva del consumidor de esa función...
public interface IExample
{
User FindUser(Guid guid);
}
Para saber qué excepciones tira tienes que leer el código de la implementación y decidir como consumidor qué te resulta relevante gestionar y qué no. Esto de base ya es un smell (code against spec not implementation). Al utilizar excepciones para definir escenarios no terminantes estás incrustando lógica del dominio en ellas, lo que hace que necesites ser consciente de qué excepciones se tiran porque están acopladas al dominio y no a un estado terminante. Algo terminante sería pasarle un yaml a un código que parsea xml. Algo del dominio es que al deserializar el XML los datos resultantes no cumplan las garantías requeridas.
El resumen continúa siendo el mismo: has perdido mucho y no has ganado nada a cambio.
No estoy inventando la rueda tampoco, con googlear "are exceptions an antipattern" te saldrá todo y podrás tirar del hilo hasta decir basta. Tampoco estoy diciendo que nunca deban usarse excepciones, sólo que no deberían usarse como control flow mechanisms.
podemos abarcar TODOS los casos, aunque no los manejemos uno a uno
Esto en concreto es un antipattern cuyo principio general es muy recurrente: limar tiempo escribiendo código a cambio de perder garantías en runtime u ofuscar la futura lectura del código. Tú que eres puntonetero si no recuerdo mal, el ejemplo canónico de mala práctica para ahorrarse tiempo escribiendo es automapper. Conviertes un compile-time issue en un runtime issue, ofuscas el código y encima a poco que necesites hacer algo complejo mueves la solución de csharp al DSL de automapper. Pierdes todo y ganas absolutamente nada.
El acto de escribir código prácticamente nunca es un bottleneck y el código está para que lo lea una persona o para que se ejecute en producción. Hacer un error explícito en vez de usar un umbrella catch siempre será mejor porque te da más información. Siempre digo lo mismo: modelar y gestionar errores es el 80% del curro de un dev.
