¿Está bien derivar de System.ArgumentException?

Question

Si tengo un método que verifica la validez de sus argumentos, ¿está bien lanzar mis propias excepciones personalizadas derivadas de System.ArgumentException? Estoy preguntando porque ArgumentException se deriva de System.SystemException y estoy viendo directrices contradictorias sobre si una aplicación debe derivar de SystemException. (Aunque de manera indirecta, derivada de ArgumentException sigue siendo equivalente a la derivada de SystemException.)

veo un montón de directrices diciendo no derivan de ApplicationException, pero se derivan de Excepción en su lugar. Estoy feliz con eso. De lo que no estoy seguro es de si está bien derivar también de SystemException.

Si no debo derivar de SystemException, ¿de qué debería derivar mis clases de excepción "invalid argument"?

Answer 1

El MSDN page about Best Practices for Handling Exceptions dice

lanzar una ArgumentException o una clase derivada de ArgumentException si se pasan los parámetros no válidos.

Así que yo diría que está bien y hasta recomendado.

Answer 2

Si desea derivar sus excepciones "argumento no válido" y que no tiene un significado más allá de eso, entonces ArgumentException suena como un candidato razonable:

ArgumentException se inicia cuando se invoca un método y al menos uno de los argumentos pasados ​​no cumple con la especificación del parámetro del método llamado. --MSDN

Answer 3

Si está 100% reutilizando las propiedades ArgumentException y agrega alguna funcionalidad adicional, estaría bien. Sin embargo, cuando solo lo reutiliza por su nombre, no estaría bien.

Answer 4

Uno de los beneficios de derivar de System.ArgumentException es que los bloques catch(System.ArgumentException) podrán manejar su tipo de excepción personalizado, así como System.ArgumentException. Esto puede o no ser lo que quieres.

Answer 5

La idea original detrás de excepciones en .Net era que las excepciones en las bibliotecas de clases base (por ejemplo los montajes del sistema) tirarían excepciones que derivan de System.Exception e informó que todas las excepciones personalizadas heredan de System.ApplicationException para diferenciar entre las excepciones y excepciones de aplicación BCL sin embargo, Microsoft ha retrocedido en esta idea y ahora sugiere que todas las excepciones heredan de System.Exception.

Mi consejo es heredar de la clase Exception más baja en el marco que tenga sentido.

Si su excepción significa algo específico que no sea un problema con este argumento, p. el tipo puede agregar semántica a la excepción (al igual que ArgumentNullException y ArgumentOutOfRangeException hacer) y luego crear una personalizada, si no, simplemente use ArgumentException y proporcione un mensaje de excepción con significado.