Raised priority based on Philip's input.

Some aspects of this may be fixed by ICE-1010. In general, however, errors during ICEfaces processing
occur too late for the standard web.xml error-page to take effect (i.e. the HTTP header has already been
modified).

Accommodating generic error pages is difficult as described above. Recommend that we re-target this to
1.6 or close as wontfix.

This used to work out of the box with 1.5 and several of our professional service application use this technique as well as the webmail project. If memory serves me correctly JSF handled the error page handling correctly once exception handling was improved in ICEfaces prior to the 1.5 release.

I just did some testing with 1.5.3 and 1.6 dr 5 and had no problems getting the error handling to work. There are however a few quirks which I'm assuming are do the AJAX bridge. If your loading a page for the first time and an application initialization or component error occurs the error page will be shown as expected. However if an error is thrown via a bean accessor method or event, then the connection monitor will just spin away. A full page refresh will cause the error redirect to occur as normal.

The preferred behavior would be for the bridge to respect the the error-page rules defined in the web.xml without having to refresh the page.

Here is a simple web.xml snippet which will catch some commen application errors and forward a user to a friendly error page.

This code can be added to any application to test the current error handling behavior, assuming error.html is created.

<!-- All errors should jump back to the login screen -->
<error-page>
<exception-type>java.lang.ClassNotFoundException</exception-type>
<location>/error.html</location>
</error-page>
<error-page>
<exception-type>javax.servlet.jsp.JspException</exception-type>
<location>/error.html</location>
</error-page>
<error-page>
<exception-type>java.lang.NullPointerException</exception-type>
<location>/error.html</location>
</error-page>
<error-page>
<exception-type>javax.faces.FacesException</exception-type>
<location>/error.html</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/error.html</location>
</error-page>

Mircea can you take a look at this. If you have any question please swing by.

The solution for this issue would be to also interpret HTTP standard messages (such as 404, 500 or 302) for the XMLHTTPRequest responses (right now the responses expect XML (UTF-8) valid bodies).

Handle HTTP 500 errors to enable servlet exception handling mechanism.
Note:
Depending were the exception occurs it may or may not propagate to the servlet container. For example if an exception will occur in a bean property modifier method the exception will be translated into an error message by the underlying JSF implementation.

If possible, we should extend this fix to extract any nested exceptions, as per the comment below from ICE-595:

Which brings us to ICE-1133, which addresses catching Exceptions, and forwarding/redirecting to application developer specified pages. The problem is, if I catch the FileNotFoundException to send out the 404, then that will circumvent the Exception/500 code mechanism. To complicate matters, the FileNotFoundException is being wrapped in a FacesException, and the code is not pulling out the causing exception, so application developers can't, as of right now, actually specifically trap FileNotFoundException with the ICE-1133 method.

Existing behavior described in ICE-595 would be sufficient if we can extract nested exceptions.

So how to decide when to let the exception propagate to the servlet container, or extract the exception and re-throw it, and also what do we do when exceptions are nested multiple levels?
In other words I'm not sure if extracting exceptions is the right thing to do, it is too late to make a decision of this kind at the framework level.

Closing this again. The previous comment explains why we cannot make the error handling mechanism work for all use cases.

I'm not saying that we should always follow the getCause() chain for every Exception, just when it's a generic FacesException, which is inherently a wrapper exception.

Apply "workaround" for the exceptions that are zealously captured & wrapped by the JSF implementations.