todas - Manejo de excepciones en una aplicación web Java

tipos de excepciones en java netbeans

Question

Estoy desarrollando una aplicación web Java de tamaño mediano con Struts como marco MVC y JDBC simple en Data Access Layer. He estado buscando las mejores prácticas de manejo de excepciones en dicha aplicación. He encontrado varios artículos, algunos de ellos contradictorios, que solo me confunde más 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, otros presentan una gran jerarquía de excepciones específicas de la aplicación para cada problema menor que pueda ocurrir en el sistema. Algunos dicen que es mejor no manejar las 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 deberían detectarse localmente, ya que delegarlas en la capa de servicio violaría la abstracción entre ambas capas. Y así.

Le agradecería mucho que me informara sobre enlaces / nombres de artículos / libros que presenten soluciones sólidas que hayan funcionado para usted en este escenario. La solución debe aclarar al menos los siguientes puntos con justificaciones:

1. ¿Dónde se capturan las SQLExceptions?
2. ¿Dónde se deben registrar las excepciones?
3. ¿Deben registrarse excepciones sin marcar?
4. ¿Se deben capturar las excepciones no marcadas en la capa de presentación, y se deben mostrar al usuario?
5. ¿Cómo se manejan las excepciones verificadas, cuáles de ellas se muestran al usuario y cómo?
6. ¿Cómo debe usarse una página de manejador de excepciones global?
7. ¿Cómo deben usarse los struts ActionErrors en este contexto?

Gracias

Answer 1

1: ¿Dónde se capturan las SQLExceptions?

En clases DAO en capa de acceso a datos. Puede, si es necesario, envolverlo con una excepción DAO personalizada. Esta excepción DAO, a su vez, debe manejarse como una excepción comprobada.

2: ¿Dónde se deben registrar las excepciones?

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

3: ¿Se deben registrar excepciones sin marcar?

Ciertamente deben ser registrados. No deberían ocurrir en el mundo real, porque son signos de un error en la lógica del código (es decir, un error del desarrollador) que debe solucionarse lo antes posible. Deben lanzarse hasta el contenedor y dejar que el contenedor los maneje con una <error-page> en web.xml . Para registrarlos (y eventualmente enviarlos), use un Filter que escuche en la página de error.

4: ¿Se deben capturar las excepciones sin marcar en la capa de presentación y se deben mostrar al usuario?

No deberían ocurrir en absoluto.

5: ¿Cómo se manejan las excepciones verificadas, cuáles de ellas se muestran al usuario y cómo?

Si son el resultado de una entrada de usuario errónea (por ejemplo, no un número, correo electrónico incorrecto, violación de restricción, etc.), muéstrelos en la misma forma al usuario. De lo contrario (p. Ej., DB bajado, excepción DAO y así sucesivamente), puede llevarlo hasta la página de error, o mostrar el error con un mensaje para volver a intentarlo más tarde.

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

Al menos de una manera fácil de usar. Por lo tanto, en el mismo diseño, con algunos "lo siento" introductorios 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 para el caso.

7: ¿Cómo deben usarse los struts ActionErrors en este contexto?

Muéstralos en la misma forma al usuario.

Answer 2

Como advertencia, cuando muestre mensajes de error de nivel inferior a los usuarios, asegúrese de que estén limpios de la información del sistema. Esta es un área donde se originan muchas vulnerabilidades de seguridad. Regístralos con información completa, pero solo muestra un mensaje de error más general para el usuario.

Answer 3

Si no puede recuperarse de una excepción, entonces debe dejar que salga de su código (a menudo, haciendo que no esté marcado o envolviéndolo en una excepción no seleccionada). Si permanecen marcados, debe atenderlos en cada nivel de su código y, en consecuencia, en cada capa de abstracción. SQLExceptions normalmente caerían en esta categoría (tendrás que envolverlas ya que están verificadas).

Para estas excepciones, normalmente inicio sesión en el nivel más alto, pero presento una página para los usuarios simplemente detallando que algo salió mal. Normalmente mis usuarios no están interesados ​​en los rastros de pila. Pero generalmente les ofrezco una página para que describan lo que estaban haciendo en ese momento, y la excepción registrada se vincula con este envío 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 atar las acciones de los usuarios a la excepción resultante.

Lo anterior asume que no puede recuperarse de SQLExceptions , y si la base de datos está inactiva, entonces no puede hacer algo significativo. Hay excepciones a esto, por supuesto. Es posible que descubra que está hablando con varios sistemas, y que uno esté inactivo no significa que no pueda continuar de alguna manera (por ejemplo, la página de inicio de Amazon se basa en 100 servicios y necesita ejecutarse independientemente de algunos de estos abajo).

Espero que las excepciones declaradas se encuentren al mismo nivel de abstracción que la interfaz / los métodos que las definen. por ejemplo, se declararía a TradeException que arrojara una TradeException , no una SQLException (dado que los métodos para almacenar una transacción son una implementación de TradeStore , puede almacenar en una base de datos relacional, un JavaSpace, etc.).