tipos - todas las excepciones en java

¿Cuál es la regla general para crear una excepción en Java?

Question

He estado en ambas situaciones:

• Crear demasiadas excepciones personalizadas
• Usar demasiadas clases generales de Excepción

En ambos casos, el proyecto comenzó bien, pero pronto se convirtió en una carga general para mantener (y refactorizar).

Entonces, ¿cuál es la mejor práctica con respecto a la creación de sus propias clases de excepción?

Answer 1

Básicamente, cada trabajo merece una excepción propia. Cuando detecta excepciones, no distingue diferentes instancias, como lo haría normalmente con los objetos, por lo tanto, necesita diferentes subtipos. Usar demasiadas excepciones personalizadas es un caso que veo que apenas ocurre.

Un consejo sería crear excepciones según sea necesario, y si resulta evidente que un tipo de excepción es un duplicado de otro, refactorice el código fusionando los dos. Por supuesto, ayuda si se piensa en la estructuración de excepciones desde el principio. Pero, en general, use excepciones personalizadas para todos los casos que no tengan correspondencia 1: 1 con las excepciones existentes, específicas de la situación.

Por otro lado, las IndexOutofBoundsException NullPointerException e IndexOutofBoundsException realidad pueden ser apropiadas. Sin embargo, no los captures (excepto para el registro) ya que son un error de programación, lo que significa que después de lanzarlos, el programa está en un estado indefinido.

Answer 2

Los Especialistas de Java escribieron una publicación sobre Excepciones en Java , y en ella se enumeran algunas "mejores prácticas" para crear Excepciones, que se resumen a continuación:

• No escriba excepciones propias (hay muchas excepciones útiles que ya forman parte de la API de Java)

• Escriba Excepciones Útiles (si tiene que escribir sus propias Excepciones, asegúrese de que brinden información útil sobre el problema que ocurrió)

Answer 3

Mi propia regla de oro:

Nunca lanzo Exception, excepto en pruebas unitarias cuando lo que lanzas es irrelevante y no hay razón para gastar tiempo extra en él.

Creo mi propio tipo de excepción personalizado para los errores que ocurren en mi lógica empresarial personalizada. Este tipo de excepción se utiliza tanto como sea posible para refundir otras excepciones, excepto en los casos en los que tiene sentido que el cliente tenga visibilidad de lo que realmente ocurrió.

Answer 4

Si no puedo encontrar una excepción que tenga un nombre que describa qué tipo de error fue causado, entonces hago mi propia.

Esa es mi regla-o-thumb.

Answer 5

No hagas lo que hicieron los desarrolladores de mi empresa. Alguien creó una InvalidArguementException [sic] que es paralela a java.lang.IllegalArgumentException, y ahora la usamos en (literalmente) cientos de clases. Ambos indican que un método ha pasado un argumento ilegal o inapropiado. Hablando de un desperdicio ...

Joshua Bloch cubre esto en la Guía de Lenguaje de Programación Java Efectivo [mi biblia de primer recurso en Mejores Prácticas] Capítulo 8. Excepciones Artículo 42: Favorezca el uso de excepciones estándar . Aquí hay un poco de lo que dice,

Reutilizar excepciones preexistentes tiene varios beneficios. Principal entre estos, hace que su API sea más fácil de aprender y usar porque coincide con las convenciones establecidas con las que los programadores ya están familiarizados [ mi énfasis, no el de Bloch ]. Una segunda aproximación es que los programas que usan su API son más fáciles de leer porque no están llenos de excepciones desconocidas. Finalmente, menos clases de excepción significan una menor huella de memoria y menos tiempo de carga de clases.

La excepción más comúnmente reutilizada es IllegalArgumentException. Por lo general, esta es la excepción que se lanza cuando la persona que llama pasa un argumento cuyo valor es inapropiado. Por ejemplo, esta sería la excepción a tirar si el que llama pasó un número negativo en un parámetro que representa el número de veces que se debe repetir alguna acción.

Dicho esto, nunca debes lanzar Exception en sí. Java tiene un grupo bien escogido, diverso y bien enfocado de excepciones integradas que cubren la mayoría de las situaciones Y describe la excepción que ocurrió lo suficientemente bien para que pueda remediar la causa.

Sea amigable con los programadores que deben mantener su código en el futuro.

Answer 6

Mi regla empírica es cuando el cliente (el que llama) razonablemente puede querer hacer algo diferente, dependiendo del tipo de excepción emitida, los tipos de excepción adicionales están garantizados. Sin embargo, la mayoría de las veces, los tipos de excepción adicionales no son necesarios. Por ejemplo, si la persona que llama está escribiendo código como

try {
doIt();
} catch (ExceptionType1 ex1) {
// do something useful
} catch (ExceptionType2 ex2) {
// do the exact same useful thing that was done in the block above
}

entonces, claramente, los tipos de excepciones adicionales no son necesarios. Demasiado a menudo veo (o me veo forzado a escribir) un código como este porque el código que se llama era excesivamente entusiasta en la creación de nuevos tipos de excepciones.

Answer 7

Al crear su propia excepción:

• Todas las excepciones deben ser un hijo de la clase Throwable

• Si desea escribir una excepción marcada que se aplica automáticamente por la regla Manejar o Declarar, necesita extender la Clase de excepción

• Si desea escribir una ejecución de tiempo de ejecución, necesita extender la clase de excepción de tiempo de ejecución.