Page History
Wiki Markup
Error handling for MyFaces Core 2.0 and later versions
Since JSF 2.0, it is possible to provide a custom javax.faces.context.ExceptionHandler or javax.faces.context.ExceptionHandlerWrapper implementation to deal with exceptions. To do that, just create your custom class, an factory that wrap/override it and add the following into your faces-config.xml:
...
...
This is an example of an ExceptionHandlerFactory, from myfaces code:
...
...
If you need a wrapper:
...
The most important method to override is ExceptionHandler.handle().
...
...
Take a look at MyFaces Core source code, to know in detail how ExceptionHandler implementations works.
...
MyFaces Core provide a custom ExceptionHandler to deal with exceptions and provide detailed information about it. Since 2.0.8/2.1.2 this is disabled on Production environments unless it enabled on web.xml file. Don't forget to provide your custom error page in this scenario, to prevent show more information than necessary.
...
...
Provide an error page
If org.apache.myfaces.ERROR_HANDLING is set to "false", or if it is undefined and the project stage is "Development", the default ExceptionHandler just throws an exception. So you can still setup an error page by adding something like this in your web.xml file:
...
Error handling for MyFaces Core 1.2 and earlier versions
...
If this is not what you want, though, you can always disable or modify this error-handling with the following parameters:
...
...
If you do this, you can now read on to get to general ways of handling server-errors.
...
For define a custom template file:
...
Use sandbox org.apache.myfaces.tomahawk.util.ErrorRedirectJSFPageHandler
...
The info of the error in the jsf page can be found using:
...
...
Using servlets
Mert Caliskan (http://www.jroller.com/page/mert?entry=handling_errors_with_an_errror) describes an approach which wraps the JSF servlet with a new servlet which delegates to the faces servlet but handles uncaught exceptions allowing the developer to redirect to a custom error page.
...
1 define an error handling web page in web.xml
...
...
2 Create the error handler display. Due to a problem with the JSF 1.1 specification, the error handling page cannot use a <f:view> but must use a subview.
...
...
3 Create a backing bean in request scope which can process the error. (don't forget to register it on faces-config.xml)
...
...
Also have a look at our ExceptionUtils class. It encapsulates the way how to get the real root cause
...
...
1 get a list of all exceptions - using getRootCause if available or getCause<<BR>>
2 get the initial exception<<BR>>
3 get the first exception with an message starting with the initial exception
So the new fillStackTrace become
...
...
In the backing bean we construct a message which informs the user that something we didnt't plan for has happened with directions on who to call, what to do etc. We don't really care if they actually do cut-and-paste the error and email it to us as it is also in Tomcat's logs but giving the user something to do and become part of resolving the problem is always a good idea 
...
Another way to handle this would be to use an intermediate step by specifying a non-JSF URL as the error page and then somehow redirecting to the JSF error page. For example, for the 404 error code you could specify ''/error/404_redirect.html'':
...
...
This works, but requires you to hard code the context path.
The solution I ended up with involves a ''RedirectServlet'':
...
...
used like this in ''web.xml'':
...
...
With plain JSP
If you didn't require any JSF functionality in your JSP page it might be worth to consider using the following error.jsp
...
with this web.xml configuration
...
This reduces the number of technologies required to show the error page which might improve the availablity of this page 
...
A fragment of your dependency plan would be like this:
...
...
This solution was tested under Apache Geronimo 2.1.3., but will probably be similar in other versions.Wiki Markup
Overview
Content Tools
Apps