Why use a JSF ExceptionHandlerFactory instead of redirection?

The particular example does only one useful thing: it saves the view ID as a request attribute so that you can use for example

<h:link value="Go back to previous page" outcome="#{currentViewId}" />

But this is not tremendously useful as the raw request URI is already available by the <error-page>‘s default request attribute javax.servlet.error.request_uri.

<h:outputLink value="#{requestScope['javax.servlet.error.request_uri']}">Go back to previous page</h:outputLink>

However one thing what a custom ExceptionHandler is really useful for is that it allows you to deal with exceptions during ajax requests. By default they have namely no single form of helpful feedback in the client side. Only in Mojarra with project stage set to “Development” you’ll see a bare JavaScript alert message with the exception message. But that’s it. There is no single form of feedback in “Production” stage. With a custom ExceptionHandler you would be able to parse the web.xml to find the error page locations, create a new UIViewRoot with it and force JSF to set ajax rendering to @all.

So, basically:

String errorPageLocation = "/WEB-INF/errorpages/500.xhtml";
context.setViewRoot(context.getApplication().getViewHandler().createView(context, errorPageLocation));
context.getPartialViewContext().setRenderAll(true);
context.renderResponse();

See also this related question: What is the correct way to deal with JSF 2.0 exceptions for AJAXified components? and this blog: Full Ajax Exception Handler.

Leave a Comment