Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

JSF2 exception handling

What's the best way to handle "unchecked" exceptions in a JSF2 webapp?

Currently, I let them flow till the servlet container, and I redirect (via the web.xml file) to a jsp error page showing a friendly message and the exception info.

Is it better to handle them with a "custom exception handler" (like Ed Burns says in the book "JSF 2.0 - The Complete Reference").

In both cases ("web.xml" or "exception handler"): Do I have to redirect to a jsp page instead of a facelet page? (because the exception maybe caused by a jsf problem itself and can result in a loop). Or can I redirect to a facelet page? Redirecting to a jsp page has the disadvantage of having to configure the jsf app to admit both jsp and facelets (it would be more "clean" having just facelet pages).

Finally, another question: The "custom exception handler" handles the "checked" exceptions too? Currently, I handle them in the managed beans (catch them and show a facesmessage in the app page).

like image 567
choquero70 Avatar asked Dec 12 '11 18:12

choquero70


1 Answers

What's the best way to handle "unchecked" exceptions in a JSF2 webapp?

It all depends on the functional requirements. Unchecked exceptions usually indicate bugs and configuration problems in your webapp. They should usually not be caught but just bubble up into the container. They are usually not enduser's fault but just developer's or serveradmin's fault.


Currently, I let them flow till the servlet container, and I redirect (via the web.xml file) to a jsp error page showing a friendly message and the exception info.

Is it better to handle them with a "custom exception handler" (like Ed Burns says in the book "JSF 2.0 - The Complete Reference").

The custom exception handler is particularly useful if you want to have a more finer grained control over exceptions on asynchronous (ajax, XMLHttp) requests as they are not handled by <error-page> in web.xml. With a custom exception handler you'll be able to navigate to a specific error page so that it will be displayed in its full glory instead of a cryptic exception message in a JavaScript alert dialog. But for exceptions on synchronous (normal HTTP) requests, it's somewhat overkill as compared to <error-page> in web.xml.


In both cases ("web.xml" or "exception handler"): Do I have to redirect to a jsp page instead of a facelet page? (because the exception maybe caused by a jsf problem itself and can result in a loop). Or can I redirect to a facelet page? Redirecting to a jsp page has the disadvantage of having to configure the jsf app to admit both jsp and facelets (it would be more "clean" having just facelet pages).

Just make sure that the exception page is free of bugs. This is regardless of whether it's a JSP or Facelets page. The bugs can creep inside JSP pages as good.


Finally, another question: The "custom exception handler" handles the "checked" exceptions too? Currently, I handle them in the managed beans (catch them and show a facesmessage in the app page).

It handles all kinds of exceptions.

like image 182
BalusC Avatar answered Nov 19 '22 02:11

BalusC