Arquitectura de manejo de excepciones para proyectos Java EE

Question

Estoy tratando de recopilar información sobre cómo otros programadores de Java EE hacen su manejo de excepciones. ¿Centraliza el manejo de errores (por ejemplo, un filtro Servlet)?

¿Creas diferentes tipos de excepciones para las diferentes capas de aplicación (persistencia, servicio, etc.)?

¿Se traga las excepciones y no las arroja a la cadena?

¿Qué otros paradigmas hay en la arquitectura de manejo de excepciones? ¿Cuál usas y por qué?

Answer 1

La capa de persistencia, si se implementa mediante JPA o Hibernate, ya tiene sus propias excepciones, que son excepciones de tiempo de ejecución.

La capa de servicio arroja excepciones de tiempo de ejecución cuando se pasan argumentos ilegales (cuando se supone que deben ser validados por la capa de presentación) o marcadas excepciones cuando ocurre un error recuperable (ejemplo: el nombre elegido ya existe en la base de datos).

Cada controlador de la capa de presentación trata las excepciones comprobadas lanzadas por los servicios comerciales que llama, para proporcionar un mensaje de error significativo y permitir que el usuario se recupere del error (ejemplo: vuelva a mostrar el formulario y pregunte al usuario para elegir otro nombre)

Todas las demás excepciones de tiempo de ejecución, provenientes de la capa de presentación, la capa empresarial o la capa de persistencia, son manejadas por uno o varios manejadores de excepciones globales (la mayoría de las infraestructuras de interfaz de usuario los admiten), que registran excepción y lanzar un mensaje de error más o menos genérico (ejemplo: "Error inesperado", "Algún otro usuario modificó o eliminó el objeto que intentó modificar").

Answer 2

Las excepciones son oro puro para que intente averiguar qué salió mal. ¡Trátelos en consecuencia!

Las excepciones de deglución solo son aceptables en los pocos casos en que en realidad es la acción adecuada.

Las excepciones comprobadas en Java generalmente lo obligan a considerar cómo manejar los errores cerca de la ubicación donde realmente ocurrió. Tenga en cuenta que puede ser perfectamente aceptable ajustar la excepción en una DomainException (o una subclase apropiada de la misma) y enviarla a la cadena de llamadas a una ubicación que realmente pueda manejarla y recuperarse correctamente.

En la mayoría de los casos tiene una captura de prueba que le permite capturar todas las excepciones y manejarlas. Es por eso que es tan importante proporcionar tanta lógica (envolviéndola en una excepción que tenga sentido para usted), por lo que este controlador puede actuar en consecuencia.

Para casos conocidos, se puede tomar la acción adecuada.

Para casos desconocidos, es una cuestión de falla muy fuerte, ya que tiene su sistema en un estado inesperado. Registre todo lo que pueda, ya que es posible que no pueda reproducirlo de otra forma, e ingrese un estado adecuado (salir, denegar el servicio adicional o simplemente continuar según corresponda para su modelo).

Answer 3

Desaconsejo firmemente la práctica de tragar excepciones. Esta es la mejor manera de perder tanto tiempo investigando el origen de un problema. Tuve tantos momentos de wtf cuando finalmente encontré la excepción oculta en una cláusula de captura vacía. Estoy de acuerdo con Thorbjørn con respecto al hecho de que la mayoría de las veces tiene una captura de prueba superior.Dentro de él me encuentro utilizando muchos métodos que pueden arrojar excepciones, y para evitar el código de manejo de errores, prefiero capturar las excepciones solo en el último nivel.
Acerca de centralización, creo que sus archivos de registro deben ser lo suficientemente centrales.