Hay algunas reglas para el manejo de excepciones que debe tener en cuenta. Pero primero, debe recordar que las excepciones son parte de la interfaz expuesta por el código; documentarlos . Esto es especialmente importante cuando la interfaz es pública, por supuesto, pero también es una muy buena idea en las interfaces privadas.
Las excepciones solo deben manejarse en el punto donde el código puede hacer algo sensato con ellas. La peor opción de manejo es no hacer nada al respecto, lo que solo debe hacerse cuando esa es exactamente la opción correcta. (Cuando tengo una situación así en mi código, incluyo un comentario al respecto para que no me preocupe por el cuerpo vacío).
La segunda peor opción es lanzar una excepción no relacionada sin el original adjunto como causa. El problema aquí es que la información dentro de la excepción original que permitiría el diagnóstico del problema se pierde; está creando algo con lo que nadie puede hacer nada (aparte de quejarse de que "no funciona", y todos sabemos cómo odiamos esos informes de errores).
Mucho mejor es registrar la excepción. Eso le permite a alguien descubrir cuál es el problema y solucionarlo, pero solo debe registrar la excepción en el punto en el que de otro modo se perdería o informaría a través de una conexión externa. Esto no se debe a que el registro más frecuente sea un problema importante como tal, sino a que el registro excesivo significa que el registro consume más espacio sin contener más información. Una vez que haya registrado la excepción, puede informar un resumen al usuario / cliente con buena conciencia (siempre y cuando también incluya el tiempo de generación u otro identificador de correlación) en ese informe para que la versión corta pueda coincidir arriba con los detalles si es necesario).
La mejor opción es, por supuesto, manejar completamente la excepción, lidiando con la situación de error en su totalidad. Si puedes hacer esto, ¡hazlo! Incluso podría significar que puede evitar tener que registrar la excepción.
Una forma de manejar una excepción es lanzar otra excepción que proporcione una descripción de nivel superior del problema (por ejemplo, " failed to initialize" en lugar de " index out of bounds"). Este es un buen patrón siempre que no pierda la información sobre la causa de la excepción; use la excepción detallada para inicializar la causeexcepción de nivel superior o registre los detalles (como se discutió anteriormente). El registro es más apropiado cuando está a punto de cruzar un límite entre procesos, como una llamada IPC, porque no hay garantía de que la clase de excepción de bajo nivel esté presente en el otro extremo de la conexión. Mantenerse como una causa adjunta es lo más apropiado al cruzar un límite interno.
Otro patrón que ves es atrapar y soltar:
try {
// ...
} catch (FooException e) {
throw e;
}
Este es un antipatrón a menos que tenga restricciones de tipo de otras catchcláusulas que significan que no puede dejar que la excepción pase sola. Entonces es solo una característica fea de Java.
No existe una diferencia real entre las excepciones verificadas y las no verificadas, aparte del hecho de que debe declarar las excepciones verificadas que cruzan los límites del método. Todavía es una buena idea documentar excepciones no verificadas (con el @throwscomentario de javadoc) si sabe que su código las arroja deliberadamente. No arrojes deliberadamente java.lang.Erroro sus subclases (a menos que estés escribiendo una implementación JVM).
Opinión: Un caso de error inesperado siempre representa un error en su código. Las excepciones marcadas son una forma de gestionar esta amenaza, y cuando los desarrolladores usan deliberadamente excepciones no verificadas como una forma de evitar el problema de manejar casos de error, está acumulando una gran cantidad de deudas técnicas que tendrá que limpiar en algún momento si quieres un código robusto El manejo descuidado de errores no es profesional (y observar el manejo de errores es una buena manera de determinar qué tan bueno es realmente un programador).