He tenido un debate entre unos pocos amigos y yo. Prefieren excepciones generales como ClientErrorExceptiony ServerErrorExceptioncon detalles como campos de la excepción, mientras que prefiero hacer las cosas más específicas. Por ejemplo, podría tener un puñado de excepciones como:
BadRequestExceptionAuthenticationFailureExceptionProductNotFoundException
Cada uno de estos se basa en el código de error devuelto por la API.
Siguiendo las ventajas de las excepciones, esto parece idiomático para Java. Sin embargo, la opinión de mis amigos no es exactamente infrecuente.
¿Existe una forma preferida en términos de legibilidad de código y usabilidad de API, o realmente se reduce a la preferencia?
abstracty generalizar las clases de excepción con los métodos getter y luego hacer que las granulares amplíen las generales. Por ejAuthenticationFaliureException extends ClientErrorException. De esta manera, cada usuario puede elegir cómo quiere lidiar con las excepciones. Sin embargo, funciona más, obviamente. Sin embargo, al escribir una aplicación (en lugar de una biblioteca), es una situación diferente en mi humilde opinión. En ese caso, no haría que las excepciones sean más granulares de lo que las necesita, por simplicidad.Respuestas:
La principal diferencia entre tener muchas clases de excepción diferentes y tener solo unas pocas, con información más detallada en el texto de error (por ejemplo), es que muchas clases de excepción diferentes permiten que el código de llamada reaccione de manera diferente a diferentes tipos de errores, mientras que tiene Solo unas pocas clases facilitan el manejo de todo tipo de excepciones de manera uniforme.
Esto suele ser una compensación. Puede mitigarse hasta cierto punto mediante el uso de la herencia (una clase de excepción de base general para las personas que llaman que desean capturar y registrar todo genéricamente, y las excepciones derivadas de esa clase de base para las personas que llaman que necesitan diferentes reacciones), pero incluso eso puede producir un mucha complejidad innecesaria si no tienes cuidado y te apegas al principio YAGNI. Entonces la pregunta guía debería estar aquí:
No hay una solución única para todo esto, no hay una "práctica recomendada" que pueda aplicar todos y cada uno. La respuesta a esta pregunta depende en gran medida del tipo de software o componente que esté diseñando:
alguna aplicación, donde usted o el equipo tiene toda la base de código bajo su control?
o algún componente reutilizable para terceros, donde no conoces a todas las personas que llaman potenciales?
Es una aplicación de servidor de larga ejecución, donde diferentes tipos de errores no deberían romper todo el sistema de inmediato y pueden requerir diferentes tipos de mitigación de errores.
un proceso de aplicación de corta duración en el que es suficiente en caso de error mostrar un mensaje de error al usuario y luego reiniciar el proceso?
Por lo tanto, cuanto más sepa acerca de las posibles llamadas de su componente, mejor podrá decidir sobre el nivel de detalle correcto para sus excepciones.
fuente
La respuesta depende de qué nivel de informe de errores estamos hablando.
En general, estoy de acuerdo con tus amigos, no debes hacerlos más granulares de lo necesario para transmitir la causa del problema.
Si hay una excepción común y bien conocida para hacer referencia a nulo (NullReferenceException), no debe crear su propia MyObjectIsNullException. Eso solo agregaría una capa de confusión para el intérprete humano, una cosa adicional que aprender que no aclara nada.
Solo cuando su excepción sea tan especial que no haya una predefinida que cubra la causa raíz, debe crear la suya propia.
Sin embargo, no tiene que detenerse allí. El error común puede ocurrir en uno de sus componentes y es posible que desee comunicar que hubo un problema en su componente . Así que no solo lo que salió mal sino también dónde. Entonces sería apropiado envolver la primera excepción en una excepción MyComponentException. Eso te dará lo mejor de ambos mundos.
Primero quedará claro que su componente tuvo problemas. En una palanca inferior, la causa específica estaría en la excepción interna.
fuente