La lectura del día recomendada llega de java.net, más en concreto versando sobre el tema de la gestión correcta de las excepciones, un quebradero de cabeza tremendamente habitual en el desarrollo de aplicaciones, y de forma muy concreta en los antipatrones más frecuentes. El artículo original en inglés eso si.
El comienzo nos lleva a una serie de dudas que habréis podido encontrar en casi cualquier grupo de trabajo a nivel de desarrollo de software en algún momento:
“Should you throw an exception, or return null? Should you use checked or unchecked exceptions? For many novice to mid-level developers, exception handling tends to be an afterthought. Their typical pattern is usually a simple try/catch/printStackTrace(). When they try to get more creative, they usually stumble into one or more common exception handling antipatterns.”
En muchos casos, se trata de viejos conocidos de antipatrones como los recubrimientos destructivos (en lugar de construir las excepciones a partir de otra) como en el caso de:
catch (NoSuchMethodException e) {
throw new MyServiceException(“Blah: ” +
e.getMessage());
}
o los utilizados indiscriminadamente en diversas capas de nuestro aplicativo como:
catch (NoSuchMethodException e) {
LOG.error("Blah", e);
throw e;
}
que transforman el resultado del análisis de logs en un auténtico infierno.
Hay otros que quizá no sean tan triviales como el hecho de usar las menores líneas de log posibles si estamos en un entorno multi-instancia para que entre medias no nos encontremos con líneas adicionales que “particionen” nuestro error. De sentido común y simple, pero que quizá nos puedan sorprender si no estamos “al loro”.
Como guía me ha parecido un documento relevante.
Además de ello sin duda como dicen en el artículo: “Good exception handling is a key to building robust, reliable systems”. Estoy totalmente de acuerdo con esta afirmación aunque el sistema de logging sin duda aquí también jugará un papel vital y clave.
Actualmente en mi empresa usamos 
Leo hoy vía 