Question

There is an option in java web applications to handle exceptions by defining error-page in web.xml:

<error-page>
<error-code>500</error-code>
<location>/error500.jsp</location>
</error-page>

I am wondering if there could potentially be a problem with defining a JSP error page (as opposed to an HTML error page).
Because JSPs run at server side. Can there be a scenario where the server is “half-dead”, throws an exception, tries to redirect to the error page, but can’t render it because of being “half-dead”?

By “half-dead” I mean that the server is in a state where some things still work, but other things don’t work. Specifically I mean that whatever controls the redirecting to the error-page defined in web.xml still works, but the actual rendering of the JSP doesn’t work for some reason (something throws an exception).

I didn’t actually see a problem like this, but I wonder if it’s possible. Because then potentially an HTML error page would work (because it has no server side logic), while the JSP error page wouldn’t work.

And if this is the case, then how can I “fall back” to the HTML error page when the JSP error page fails?
I still want to use the JSP error page for displaying the error details that came back on the response, but if it’s not possible then I want to show the HTML page.

I hope that makes sense….

Answer 1

I found a solution:

1. Define the error 500 to redirect to a servlet (instead of a page)
2. Define also a 404 error page – make it a simple HTML page.
3. In the servlet, redirect to the JSP error 500 page.
4. All the logic in the servlet is surrounded with a try-catch block. The catch block does response.sendError(HttpServletResponse.SC_NOT_FOUND); which will redirect to the error 404 page defined in web.xml.