¿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 de excepción generales

En ambos casos, el proyecto comenzó bien, pero pronto se convirtió en una sobrecarga de mantenimiento (y refactorización).

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

Answer 1

Los especialistas en Java escribió una publicación sobre Excepciones en Java, y en él enumeran algunas "mejores prácticas" para crear excepciones, que se resumen a continuación:

• No escriba sus propias excepciones (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 proporcionen información útil sobre el problema que ocurrió)

Answer 2

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

Joshua Bloch cubre esto en Guía eficaz del lenguaje de programación Java [mi biblia de primer recurso sobre mejores prácticas] Capítulo 8.Excepciones Artículo 42:Favorecer el uso de excepciones estándar.Aquí un poco de lo que dice,

Reutilizar excepciones preexistentes tiene varios beneficios.La principal de ellas es que 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].Un segundo lugar es que los programas que utilizan 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 dedicado a cargar clases.

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

Dicho esto, deberías nunca lanzar la excepción en sí.Java tiene un conjunto de excepciones integradas bien elegidas, diversas y bien orientadas que cubren la mayoría de las situaciones. Y Describa la excepción que ocurrió lo suficientemente bien como para que pueda remediar la causa.

Sea amigable con los programadores que tendrán que mantener su código en el futuro.

Answer 3

Mi regla general es que cuando el cliente (la persona que llama) podría razonablemente querer hacer algo diferente, dependiendo del tipo de excepción lanzada, los tipos de excepción adicionales están justificados.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 excepción adicionales no son necesarios.Con demasiada frecuencia veo (o me veo obligado a escribir) código como este porque el código que se llama fue demasiado entusiasta en la creación de nuevos tipos de excepción.

Answer 4

Si no puedo encontrar una excepción que tenga un nombre que describa qué tipo de error fue causado, entonces creo la mía propia.

Ésa es mi regla general.

Answer 5

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

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 un poco en estructurar las excepciones desde el principio.Pero, en general, utilice excepciones personalizadas para todos los casos que no tengan una correspondencia 1:1 con las excepciones existentes específicas de la situación.

Por otro lado, NullPointerExceptionarena IndexOutofBoundsExceptionEn realidad, s podría ser a menudo apropiado.Sin embargo, no los detecte (excepto para el registro), ya que son un error de programación, lo que significa que después de lanzarlos, el programa se encuentra en un estado indefinido.

Answer 6

Mi propia regla general:

Nunca lanzo una excepción, excepto en pruebas unitarias cuando lo que arrojas es irrelevante y no hay razón para dedicarle más tiempo.

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 reformular otras excepciones, excepto en los casos en los que tiene sentido que el cliente tenga visibilidad de lo que realmente ocurrió.

Answer 7

Mientras crea su propia excepción:

• Todas las excepciones deben ser hijos del Clase arrojable

• Si desea escribir una excepción marcada que la regla de manejo o declaración aplica automáticamente, debe extender el Clase de excepción

• Si desea escribir una excepción en tiempo de ejecución, debe ampliar la clase de excepción en tiempo de ejecución.

Answer 8

No comas excepciones, tíralas. https://stackoverflow.com/a/921583/1097600

Evite crear su propia excepción.Utilice los siguientes que ya están allí.

IllegalStateException
UnsupportedOperationException
IllegalArgumentException
NoSuchElementException
NullPointerException

Lanzar excepciones no marcadas.

Ejemplo

public void validate(MyObject myObjectInstance) {
    if (!myObjectList.contains(myObjectInstance))
        throw new NoSuchElementException("object not present in list");
}