¿Por qué crear excepciones personalizadas?

Question

¿Por qué tenemos que crear excepciones personalizadas en .NET?

Answer 1

excepciones específicas de aduanas le permiten segregar diferentes tipos de error sobre sus declaraciones de capturas.La construcción común para el manejo de excepciones es la siguiente:

try 
{} 
catch (Exception ex) 
{} 

Esto llama todas las excepciones independientemente del tipo. Sin embargo, si usted tiene excepciones personalizadas, puede hacer que los controladores independientes para cada tipo:

try 
{} 
catch (CustomException1 ex1) 
{ 
    //handle CustomException1 type errors here 
} 
catch (CustomException2 ex2) 
{ 
    //handle CustomException2 type errors here 
} 
catch (Exception ex) 
{ 
    //handle all other types of exceptions here 
} 

Ergo, las excepciones específicas que un mayor nivel de control sobre el manejo de excepciones permite. Este beneficio se comparte no solo por excepciones personalizadas, sino también por todos los demás tipos de excepciones en las bibliotecas del sistema .NET.

Answer 2

No estoy seguro de por qué "técnicamente" pero digamos que tengo una aplicación/sitio web que usa permisos. Si alguien no tiene el permiso correcto, es un poco estúpido lanzar una excepción DivideByZero o IOException. En su lugar, puedo crear mi AccessDeniedException que me ayudará a depurar más adelante.

Answer 3

Así que usted también puede arrojarlos usted mismo, y luego atraparlos y saber exactamente lo que significan.

También: si está creando una biblioteca de clases/framework/api, a menudo es útil crear una BaseException de la que hereden otras excepciones en su código. Luego, cuando su código genera excepciones, los programadores que lo utilizan pueden conocer rápidamente el origen de la excepción.

Answer 4

Porque puede aclarar sus intenciones, y también puede rastrear usos utilizando la funcionalidad IDE. Digamos que tiene un sistema de servidor personalizado llamado "FooBar" y realiza una "FooBarDownException", puede rastrear los usos de esta excepción para identificar cualquier lógica personalizada que contenga su aplicación porque FooBar está inactivo. Puede elegir capturar este tipo específico de excepción e ignorar otras, evitando sobrecargas y lógica condicional dentro de los manejadores de excepciones. Realmente es solo otra versión de tipeo fuerte. También significa que puede evitar comentarios en su código porque la excepción tiene un con el nombre revelador.

Answer 5

Es la misma razón por la que crearía diferentes códigos de salida para una aplicación que no es .NET: para especificar diferentes errores específicos de la aplicación. Como ... ConnectionBrokenException o um ... UserSmellsBadException ... o algo así.

De esta manera usted puede saber exactamente qué salió mal y actuar de manera apropiada. Por ejemplo, si intenta enviar algunos datos y la clase de transporte de datos arroja un ConnectionBrokenException, puede abrir un cuadro de diálogo de reconexión e intentar volver a conectar. Luego, el método de reconexión arrojaría un ConnectionTimeoutException si se agota el tiempo de espera, y usted puede volver a actuar apropiadamente.

Answer 6

Las excepciones .NET estándar no cubren todo lo malo que puede salir mal en ninguna aplicación ni su intención. A menos que su programa sea muy simple, es probable que deba crear al menos algunas excepciones personalizadas.

Answer 7

Como escribió Joel: Entonces usted también puede tirarlos usted mismo, y luego atraparlos y saber exactamente lo que significan.

Además, puede agregar información específica sobre el problema para permitir que su manejador de excepciones actúe con mayor precisión.

Answer 8

lo hice una larga entrada de blog sobre este tema recientemente:

http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

El quid de la cuestión se reduce a: Sólo crear una excepción personalizada si uno de lo siguiente es cierto

1. De hecho, esperas que alguien lo maneje.
2. desea registrar información sobre un error en particular

Answer 9

Por un lado, las excepciones se implementan en la biblioteca, no en el idioma: ¿cómo pueden crear excepciones en la biblioteca? Estoy bastante seguro de que no defiende que las bibliotecas del sistema deben tener un conjunto diferente de reglas.

Por otro lado, es posible utilizar un árbol de objetos de excepciones. Sus excepciones heredadas pueden tener atributos especiales si lo desea; pueden usarse para cosas más complicadas de lo que son. No defiendo que se utilicen como un mecanismo de transporte de datos genérico ni nada (aunque podrían serlo), pero podría ver un caso en el que alguien implementó una solución de registro personalizada que requería un atributo especial en la Excepción ...

Sus excepciones personalizadas podrían contener una bandera que indique un tratamiento especial (tal vez una que diga que debe reiniciar la JVM), podrían contener información sobre los niveles de registro, un montón de cosas.

De todos modos, no estoy abogando por esto, solo digo que es posible. El primer párrafo es tu respuesta real.

Answer 10

No debe hacerlo si las Excepciones incorporadas describen adecuadamente el problema/excepción. No crearía mis propias clases base para crear una personalizada ArgumentException, ArgumentNullException o InvalidOperationException.

Puede crear sus propias excepciones y describir el error en un nivel superior. sin embargo, esto generalmente no ayuda mucho en la depuración de una clase de consumidores.

Si tira y atrapa la excepción usted mismo, una excepción personalizada puede estar en orden.

Answer 11

Otra razón, cuando un cliente habla con interfaces. Como el cliente desconoce las implementaciones de la interfaz y puede arrojar excepciones diferentes, es un buen lugar para crear excepciones personalizadas para uniformar los errores lanzados.

escribí sobre este caso especial:

http://blog.mikecouturier.com/2010/01/creating-custom-exceptions-in-net-right.html