Java, excepciones específicas de clase frente a excepciones estándar

Question

He estado actualizando una biblioteca existente para generar excepciones que ayuden a mejorar la eliminación de errores por parte de las personas que usan la biblioteca.

Al principio, pensé en definir excepciones específicas para cada clase, sin embargo resulta que la mayoría de esas excepciones son simplemente extensiones de excepciones de tiempo de ejecución existentes (por ejemplo, FooNegativeIntArgumentException extends IllegalArgumentException, FooNullBarException extends NullPointerException) con mensajes específicos.

¿Cuáles son las ventajas y desventajas de definir nuevas excepciones frente a las existentes? ¿Hay convenciones/mejores prácticas?

Además, dada la necesidad de compatibilidad con versiones anteriores, la mayoría (si no todas) de estas excepciones son excepciones de tiempo de ejecución.

Answer 1

Aquí está my take on why we have different types of exception and when to create custom exception types (nota: esto utiliza los tipos .NET como ejemplos, pero los mismos principios se aplican a Java y a cualquier otro lenguaje que utilice el manejo de errores estructurados).Probablemente sea demasiado largo para publicar aquí como una respuesta completa, así que solo publicaré los dos extractos clave.

1. Cuando a lanzar diferentes tipos de excepción? Lanza un tipo diferente de excepción para cada síntoma que se puede manejar de forma diferente.

2. Cuándo crear tipos de excepción personalizados? Cree un tipo de excepción personalizado cuando necesite anotar la excepción con información adicional para ayudar en el manejo programático del síntoma.

En el caso de que no suena como sus tipos de excepción personalizados están llenando un vacío en los síntomas que pueden ser transmitidos utilizando excepciones estándar, y que no va a agregar cualquier información adicional para el manejo programático, así que no los crees. Solo use los estándares en su lugar.

Answer 2

Extender las excepciones sin agregar ningún valor como este es una pérdida de tiempo completa e incurre en un costo de mantenimiento continuo que es mejor evitar.

Use las excepciones estándar.

Esto no quiere decir que nunca deba usar excepciones personalizadas, simplemente no en los casos de uso que presente.

Además, al crear excepciones personalizadas, deben estar relacionadas con las condiciones que las causan, no con la clase desde la que se lanzarán. Está bien relacionarlos con un área comercial/funcional, ya que las condiciones de error que causan excepciones probablemente estén relacionadas de esta manera, y proporcionará técnicas de filtrado útiles.

Answer 3

Trade-off? Mucho trabajo, mucho código para mantener y tiempo es dinero. Sugeriría: defina nuevas excepciones solo si las necesita para filtrar registros, manejo de excepciones de granularidad fina o depuración (establezca un punto de interrupción para un tipo de excepción especial).

Answer 4

Usaría excepciones explícitamente definidas para dar más control al código del cliente. Si el cliente lo desea, puede capturar IllegalArgumentException como en su ejemplo anterior. Si necesitan más control, pueden detectar tipos de excepciones individuales. Considere, por ejemplo, un método que podría lanzar dos subclases de IllegalArgumentException. Si no hace una subclase, debe realizar el análisis sintáctico de cadenas o alguna otra tontería para determinar la causa real de la excepción lanzada. Los tipos definidos por el usuario resuelven este problema.

Answer 5

¿Es probable que una persona que llama debería atrapar FooNegativeIntArgumentException en lugar de IllegalArgumentException?

Supongo que casi nunca sucederá, por lo que me quedaré con las excepciones básicas hasta que haya casos en los que se pueda ver que se necesita tal diferenciación.

Answer 6

De Effective Java

Se debe favorecer el uso de excepciones estándar y el uso de las bibliotecas de la plataforma Java conjunto de excepciones sin marcar, que cubre lo que usted ha descrito. La reutilización de excepciones tiene las siguientes ventajas:

hace que su API más fácil de aprender y usar, ya que coincide con las convenciones establecidas con las que los programadores ya están familiarizados

Menos clases de excepción significa un menor consumo de memoria y menos clases de carga en tiempo pasado.