Manejo de excepciones en una aplicación web Java

Question

Estoy desarrollando una aplicación web Java de tamaño medio con Struts como framework MVC y JDBC simple en Data Access Layer. He estado buscando las mejores prácticas de manejo de excepciones en una aplicación de este tipo. He encontrado varios artículos, algunos de ellos contradictorios, solo me hacen estar más confundido en lugar de dejar las cosas claras y simples. Algunos dicen que es mejor reutilizar las excepciones existentes en lugar de definir excepciones específicas de la aplicación, mientras que otras presentan una gran jerarquía de excepciones específicas de la aplicación por cada problema menor que pueda ocurrir en el sistema. Algunos dicen que es mejor no manejar excepciones en la capa de acceso a datos y delegarlas en la capa de servicio, otros dicen que las excepciones de la capa de acceso a datos deben capturarse localmente ya que delegarlas en la capa de servicio violaría la abstracción entre las dos capas. Y así.

Agradecería mucho que me informara acerca de los enlaces/nombres a los artículos/libros que presentan soluciones sólidas que le han funcionado en ese escenario. La solución debe borrar al menos los siguientes puntos con justificaciones:

1. ¿Dónde se pueden atrapar las SQLExceptions?
2. ¿Dónde deberían registrarse las excepciones?
3. ¿Deben registrarse las excepciones sin marcar?
4. ¿Deben capturarse las excepciones sin marcar en la capa de presentación y deben mostrarse al usuario?
5. ¿Cómo se manejan las excepciones controladas, cuál de ellas se mostrará al usuario y cómo?
6. ¿Cómo se debe usar una página de manejador de excepción global?
7. ¿Cómo se debe usar struts ActionErrors en este contexto?

Gracias

Answer 1

1: ¿Dónde se pueden atrapar las SQLExceptions?

En clases DAO en la capa de acceso a datos. Si es necesario, puede envolverlo con una excepción DAO personalizada. Esta excepción DAO a su vez debe manejarse más como una excepción marcada.

2: ¿Dónde deberían registrarse las excepciones?

En el momento en que está a punto de throw o pasar por el marco de mensajería.

3: ¿Deberían registrarse las excepciones no marcadas?

Sin duda se deben registrar. Deberían saber no ocurrir en el mundo real, porque esos son signo de una falla en la lógica del código (es decir, falla del desarrollador) que debe corregirse lo antes posible. Deben arrojarse hasta el contenedor y dejar que el contenedor los maneje con un <error-page> en web.xml. Para registrarlas (y eventualmente enviarlas por correo), use Filter que escucha en la página de error.

4: ¿Deberían capturarse excepciones sin marcar en la capa de presentación, y deberían mostrarse al usuario?

No deberían ocurrir en absoluto.

5: ¿Cómo se manejan las excepciones controladas, cuál de ellas se mostrará al usuario y cómo?

Si son el resultado de una entrada errónea del usuario (por ejemplo, no un número, correo electrónico incorrecto, violación de restricción, etc.), muéstrelos de la misma forma al usuario. De lo contrario (por ejemplo, DB inactivo, excepción de DAO, etc.) o lo arroja todo el camino hasta la página de error, o muestra el error con un mensaje para intentarlo más tarde.

6: ¿Cómo se debe usar una página de manejador de excepción global?

Al menos de una manera fácil de usar. Por lo tanto, en el mismo diseño, con algunos "perdón" de presentación y, si es necesario, con algunos detalles de error y una dirección de correo electrónico para que el usuario pueda ponerse en contacto con el caso.

7: ¿Cómo se debe usar struts ActionErrors en este contexto?

Mostrar de la misma forma para el usuario.

Answer 2

Si no puede recuperarse de una excepción, entonces usted debe dejar que fluya fuera de su código (a menudo por lo que no se controla, o envolviéndolo en una excepción sin marcar). Si permanecen controlados, debe atenderlos en cada nivel de su código y, en consecuencia, en cada capa de abstracción. SQLExceptions normalmente caería en esta categoría (tendrá que envolverlos ya que están marcados).

Para estas excepciones, normalmente me registro al más alto nivel, pero presento una página a los usuarios simplemente detallando que algo ha salido mal. Normalmente mis usuarios no están interesados ​​en los rastros de pila. Pero generalmente les ofrezco una página para que puedan describir lo que estaban haciendo en ese momento, y la excepción registrada se relaciona con esta presentación a través de una identificación única (registrada en el formulario y en el archivo de registro con la excepción). Eso me permite relacionar las acciones de los usuarios con la excepción resultante.

Lo anterior supone que no puede recuperar desde SQLExceptions, y si la base de datos está inactiva, no puede hacer algo significativo. Hay excepciones a esto, por supuesto. Es posible que descubras que hablas con múltiples sistemas, y que estar deprimido no significa que no puedas continuar de alguna forma (p. Ej., La página de inicio de Amazon depende de 100 servicios y necesita ejecutarse independientemente de que algunos de ellos sean abajo).

Esperaría excepciones declaradas para estar en el mismo nivel de abstracción que la interfaz/métodos que las definen. p.ej. un TradeStore se declararía arrojar un TradeException, no un SQLException (dado que los métodos de almacenamiento de una operación son una implementación de TradeStore - se podría almacenar en un DB relacional, un JavaSpace, etc.).

Answer 3

Como advertencia, al mostrar mensajes de error de nivel inferior a los usuarios, asegúrese de que estén desinfectados con la información del sistema. Esta es un área donde se originan muchos exploits de seguridad. Regístrelos con información completa, pero solo muestre un mensaje de error más general para el usuario.