Why use a JSF ExceptionHandlerFactory instead of <error-page> redirection?

Question

All of the ExceptionHandlerFactory examples I have come across so far redirect a user to a viewExpired.jsf page in the event that a ViewExpiredException is caught:

public class ViewExpiredExceptionExceptionHandler extends ExceptionHandlerWrapper {
    private ExceptionHandler wrapped;

    public ViewExpiredExceptionExceptionHandler(ExceptionHandler wrapped) {
        this.wrapped = wrapped;
    }

    @Override
    public ExceptionHandler getWrapped() {
        return this.wrapped;
    }

    @Override
    public void handle() throws FacesException {
        for (Iterator<ExceptionQueuedEvent> i = getUnhandledExceptionQueuedEvents().iterator(); i.hasNext();) {
            ExceptionQueuedEvent event = i.next();
            ExceptionQueuedEventContext context = (ExceptionQueuedEventContext) event.getSource();

            Throwable t = context.getException();
            if (t instanceof ViewExpiredException) {
                ViewExpiredException vee = (ViewExpiredException) t;
                FacesContext facesContext = FacesContext.getCurrentInstance();
                Map<String, Object> requestMap = facesContext.getExternalContext().getRequestMap();
                NavigationHandler navigationHandler = facesContext.getApplication().getNavigationHandler();
                try {
                    // Push some useful stuff to the request scope for use in the page
                    requestMap.put("currentViewId", vee.getViewId());
                    navigationHandler.handleNavigation(facesContext, null, "/viewExpired");
                    facesContext.renderResponse();
                } finally {
                    i.remove();
                }
            }
        }

        // At this point, the queue will not contain any ViewExpiredEvents. Therefore, let the parent handle them.
        getWrapped().handle();
    }
}

It seems to me that the following simple web.xml configuration is fundamentally the same and a lot simpler:

<error-page>
    <exception-type>javax.faces.application.ViewExpiredException</exception-type>
    <location>/viewExpired.jsf</location>
</error-page>

This prompts the question - why would one use an ExceptionHandlerFactory?

Buckley

Is the code above yours? if not, can you credit the source? – Hulk

Answer 1

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.

Languishment

Can OmniFaces org.omnifaces.exceptionhandler.FullAjaxExceptionHandlerFactory be used along with handling exceptions by creating an ExceptionHandlerFactory this way to divert to global error page(s), when exceptions are thrown which are not to be wrapped by this factory? The documentation requires only one exception handler factory per application, "There must be one ExceptionHandlerFactory instance per web application that is utilizing JavaServer Faces. This instance can be acquired, in a portable manner, by calling." This works well forwarding to a global error page, by the way. – Prostatitis

@Tiny: you can extend it. See also javadoc. Override shouldHandleExceptionRootCause() to return false (and add that fatal message). – Languishment

Can we catch Exception by their http error code (exemple 500 or 403) ? – Lymphoblast

@Hani: No. In order to be able to return and display a full error page via ajax, the ajax response itself has to be successful. See also https://mcmap.net/q/24418/-exception-handling-for-ajax-requests-in-jsf-using-omnifaces-always-showing-status-code-200-instead-of-500 – Languishment

Answer 2

It depends what do you want to do when you recive ViewExpiredException.

If you just want to display to a user error page you can do it like you said.

This post show you how to programmatically intercept the ViewExpiredException and do something nice with it.

Bolingbroke