2012-10-12 99 views
39

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.)¿Está bien derivar de System.ArgumentException?

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

+2

Si los parámetros proporcionados no son válidos, se espera que el método arroje una 'ArgumentException'. Puede derivar perfectamente de ella para usar en tales casos.Derivar de 'SystemException' no tiene sentido, pero arrojas una' ArgumentNullException' si un argumento es nulo o 'ArgumentOutOfRangeException' si está fuera del rango aceptable. Ambos se derivan de 'ArgumentException'. Por lo tanto, lanzar una excepción personalizada que no se derive de 'ArgumentException' en tales casos es en mi humilde opinión algo que * no debería * hacer. Así que iría con la respuesta de Botz3000. –

Respuesta

40

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.

+0

Gracias, Botz, tu respuesta me ha convencido de usar ArgumentException. –

5

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

2

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.

7

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.

4

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.

+0

Se suponía que las excepciones de usuario derivaban de ApplicationException, no SystemException. –

+0

Bien manchado, escribí una excepción con demasiada frecuencia en esa publicación, ¡la corregiré! –

Cuestiones relacionadas