That depends on how/where you're catching them. Normally, you'd like to specify an <error-page>
in web.xml
for that like so:
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.html</location>
</error-page>
This basically shows the error.html
page for any e instanceof java.lang.Exception
.
Another way is to catch it in a Filter
listening on an url-pattern
of /*
:
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException {
try {
chain.doFilter(request, response);
} catch (Exception e) {
request.setAttribute("exception", e);
request.getRequestDispatcher("/error.html").forward(request, response);
}
}
This does basically the same, you've only a bit more freedom in controlling the response and doing other stuff like logging.
Either way, it will fail whenever the response is already committed (i.e. the headers are already sent to the client side). You should then have noticed an IllegalStateException: response already committed
in the server logs and the client will face a halfbaked (or even blank) page. This is a point of no return. You'd like to execute any business logic before rendering of the response. It's also one of the reasons that it's considered bad practice to do the business logic in the view (JSP/Facelets) side.