2011-12-12 42 views
5

¿Cuál es la mejor forma de manejar excepciones "no verificadas" en una aplicación web JSF2?Manejo de excepciones JSF2

Actualmente, les dejo fluir hasta el contenedor de servlets, y redirijo (a través del archivo web.xml) a una página de error jsp que muestra un mensaje amistoso y la información de excepción.

¿Es mejor tratarlos con un "manejador de excepción personalizada" (como Ed Burns dice en el libro "JSF 2.0 - The Complete Reference").

En ambos casos ("web.xml" o "gestor de excepciones"): ¿Tengo que redirigir a una página JSP en lugar de una página facelet? (porque la excepción puede ser causada por un problema jsf en sí mismo y puede dar como resultado un bucle). ¿O puedo redireccionar a una página de facelet? El redireccionamiento a una página jsp tiene la desventaja de tener que configurar la aplicación jsf para admitir tanto jsp como facelets (sería más "limpio" tener solo páginas de facelet).

Por último, otra pregunta: ¿El "manejador de excepción personalizada" maneja las excepciones "controladas" también? Actualmente, los manejo en los beans gestionados (captúralos y muestra un mensaje de caras en la página de la aplicación).

Respuesta

6

¿Cuál es la mejor manera de manejar las excepciones "no verificadas" en una aplicación web JSF2?

Todo depende de los requisitos funcionales. Las excepciones no verificadas generalmente indican errores y problemas de configuración en su aplicación web. Por lo general, no deben ser atrapados, sino simplemente burbujear en el contenedor. Por lo general, no son culpa del usuario final, sino solo culpa del desarrollador o serveradmin.


Actualmente, dejo que fluyan hasta el contenedor de servlets, y redirigen (a través del archivo web.xml) a una página de error JSP mostrando un mensaje amable y la información es una excepción.

Es mejor manejarlos con un "controlador personalizado de excepciones" (como dice Ed Burns en el libro "JSF 2.0 - The Complete Reference").

El manejador de excepción personalizada es particularmente útil si se quiere tener un control más preciso sobre excepciones más fino en asíncrono (Ajax, xmlhttp) las solicitudes, ya que no son manejados por <error-page> en web.xml. Con un manejador de excepciones personalizado, podrá navegar a una página de error específica para que se muestre en toda su gloria en lugar de un mensaje de excepción críptico en un cuadro de diálogo de alerta de JavaScript. Pero para excepciones en solicitudes síncronas (HTTP normales), es algo exagerado en comparación con <error-page> en web.xml.


En ambos casos ("web.xml" o "gestor de excepciones"): ¿Tengo que redirigir a una página JSP en lugar de una página facelet? (porque la excepción puede ser causada por un problema jsf en sí mismo y puede dar como resultado un bucle). ¿O puedo redireccionar a una página de facelet? El redireccionamiento a una página jsp tiene la desventaja de tener que configurar la aplicación jsf para admitir tanto jsp como facelets (sería más "limpio" tener solo páginas de facelet).

Solo asegúrese de que la página de excepción esté libre de errores. Esto es independientemente de si se trata de una página JSP o Facelets. Los errores pueden arrastrarse dentro de las páginas JSP como bueno.


Por último, otra pregunta: ¿El "manejador de excepción personalizada" se encarga de la "marcada" excepciones también? Actualmente, los manejo en los beans gestionados (captúralos y muestra un mensaje de caras en la página de la aplicación).

Maneja todo tipo de excepciones.

+0

Gracias BaluC. Solo una pregunta: ¿no es una mala práctica usar una página de error de facelet? (solo muestra un mensaje y la información de excepción). Funciona incluso si la excepción es causada por el marco jsf? – choquero70

+0

Bueno, si la excepción es causada por algún error en la implementación de JSF, entonces probablemente no solo se manifestará en la página de error, sino también en todas las demás páginas. – BalusC

+0

Tiene usted razón ... pero en ese caso (manifestándose en otras páginas JSF), si tenemos una página de error JSP, mostraría el error correctamente. De lo contrario, si tuviéramos una página de error Facelets, no funcionaría. Entonces, ¿no es mejor que la página de error sea JSP? Me gustaría que la respuesta sea NO, para que no tenga mezclados JSP y Facelets en la aplicación :) Pero me temo que es SÍ. ¿Qué usas en tus aplicaciones, un JSP o una página de error de Facelet? – choquero70