¿Por qué crear excepciones personalizadas?

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

Las excepciones de aduana específicas le permiten segregar diferentes tipos de error para sus declaraciones de captura. La construcción común para el manejo de excepciones es esta:

 try {} catch (Exception ex) {} 

Esto capta todas las excepciones independientemente del tipo. Sin embargo, si tiene excepciones personalizadas, puede tener manejadores separados 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 le permiten un nivel más fino de control sobre el manejo de su excepción. 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.

Hice una larga publicación en el 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: solo crear una excepción personalizada si uno de los siguientes es verdadero

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

Entonces también puedes arrojarlos tú mismo, y luego atraparlos y saber exactamente lo que significan.

Además: si está creando una biblioteca / framework / api de clase, 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 progtwigdores que lo utilizan pueden conocer rápidamente el origen de la excepción.

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 los comentarios en su código porque la excepción tiene un nombre revelador de intención .

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.

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 una excepción 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 una ConnectionTimeoutException si se agota el tiempo de espera, y usted puede volver a actuar apropiadamente.

Como Joel escribió: Entonces también puedes arrojarlos tú 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.

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

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 progtwig sea muy simple, es probable que deba crear al menos algunas excepciones personalizadas.

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, en realidad es posible usar 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 estoy defendiendo que se utilicen como un mecanismo genérico de transporte de datos 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.

No debe hacerlo si las Excepciones integradas describen adecuadamente el problema / excepción. No crearía mis propias clases base para crear una 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.