exception - salida - propagacion de excepciones en java

¿Qué factores deben tenerse en cuenta al escribir una clase de excepción personalizada?

Question

¿Cuándo son más valiosas las clases de excepción personalizadas ?
¿Hay casos en los que deberían o no deberían usarse? ¿Cuales son los beneficios?

Preguntas relacionadas:

1. Consideraciones de rendimiento para arrojar excepciones
2. ¿Escribes excepciones para problemas específicos o excepciones generales?

Answer 1

Preguntas que debe hacerse:

1. ¿Quién lo va a atrapar? Si no hay nadie, entonces realmente no necesita una excepción personalizada.
2. ¿Dónde lo vas a tirar? ¿Hay suficiente contexto disponible o tendrá que atrapar y volver a lanzar varias veces antes de que la excepción sea útil para el receptor final?
3. ¿Por qué lo estás arrojando? ¿Porque atrapó una excepción y necesita adjuntar información adicional? ¿Porque encontró un error irrecuperable en algunos datos y necesita comunicar los detalles al código del cliente? Porque te gusta throw cosas?
4. ¿Cuál es la excepción? ¿No es qué lo causó sino qué es desde la perspectiva del receptor ? Algo que pueden arreglar y volver a intentar? Algo que nunca deberían volver a intentar? Algo sobre lo que deberían notificar al usuario? ¿Algo a lo que deberían adjuntar información de contexto y luego volver a lanzar? Lo que determina la información que necesitará pasar, si hay alguno ...

Preceptos:

1. No pierda el tiempo en excepciones personalizadas que nunca serán atrapadas.
2. No duplique las excepciones: cada tipo de excepción personalizada debe tener un caso bien definido donde pueda y deba capturarse; las excepciones que no coinciden deben desglosarse en sus propios tipos personalizados (en lugar de, por ejemplo, forzar al receptor a construir una lógica condicional en una sola cláusula catch() ).
3. A menos que tenga una buena razón para no hacerlo, siempre permita adjuntar una excepción / datos internos de una excepción detectada previamente. Perder el contexto raramente es útil.

Answer 2

Hace un tiempo escribí una entrada de blog sobre cuándo lanzar diferentes tipos de excepciones y cuándo crear nuevos tipos de excepción . No es tan largo, pero probablemente sea demasiado largo para pegar aquí, así que discúlpeme por solo vincularlo. Debe cubrir su pregunta sobre por qué existen diferentes tipos de excepción y cómo saber si necesita crear una personalizada.

Answer 3

Mi principal razón para usar excepciones personalizadas sería la encapsulación con múltiples proveedores: tener una fuga SqlException fuera de una capa SqlDataAccess, y una excepción SocketException de una capa NetworkDataAccess hace que el código de llamada dependa de los detalles de su implementación. Mejor envolverlos en una DataAccessException o algo así.

Answer 4

Soy un poco minimalista y solo crearé una excepción personalizada si hay un código de llamada que debe reaccionar explícitamente a la condición particular que se produjo. Para todas las demás situaciones, usaré la excepción de biblioteca .NET más apropiada. Eg ArgumentNullException, InvalidOperationException

Answer 5

Cuando necesita distinguir una excepción de las otras de alguna manera. Eso es todo, realmente. Por supuesto, podrías crear una clase de excepción que tome una enumeración para distinguir su causa, también.

Esto es realmente fácil de ver cuando desea pasar información adicional con la excepción. La única razón para pasar esa información es si desea obtener esa información más adelante, por lo que querrá saber el tipo para que pueda recuperar la información de ese tipo y no de otros.

En C ++, y tal vez en otros idiomas, también puede escribir una excepción. Esto permitiría distinguir el tipo, y posiblemente la conversión futura a una clase personalizada.

Answer 6

Creo que la respuesta simple es "Crear una excepción personalizada cuando ninguna excepción existente exprese adecuadamente la situación excepcional".

También tengo una segunda regla que aplico: "Solo cree una excepción personalizada si espera que un desarrollador pueda manejar la excepción". No tiene sentido crear una nueva excepción si no considera la excepción como una condición recuperable. Es más eficaz lanzar InvalidOperationException en ese contexto.

EDITAR: Terminó escribiendo una publicación de blog sobre este tema: http://blogs.msdn.com/jaredpar/archive/2008/10/20/exclusiones-personalizadas-cuando-sea-usted-crease-los.aspx

Answer 7

Como dijo Wheelie , primero busque una excepción de marco apropiado, y solo use excepciones (especialmente excepciones personalizadas) donde realmente planea atraparlas.

Utilizo una clase de excepción personalizada que contiene una propiedad de UserMessage, de modo que puedo propagar el problema en un lenguaje sencillo para el usuario cuando sea posible.

Si está utilizando .NET, consulte Diseño de excepciones personalizadas . Curiosamente, la documentación ha cambiado su recomendación sobre el uso de ApplicationException:

Si está diseñando una aplicación que necesita crear sus propias excepciones, se le recomienda derivar excepciones personalizadas de la clase Excepción. Originalmente se pensó que las excepciones personalizadas deberían derivar de la clase ApplicationException; sin embargo, en la práctica esto no se ha encontrado para agregar un valor significativo. Para obtener más información, vea las Mejores prácticas para manejar excepciones.