Servlets and JavaServer Pages: The J2EE Technology Web Tier

[ directory ]

JSP and Servlet Exceptions

With JSP and Servlets it is imperative to always catch exceptions. Should an exception be thrown from either a JSP or Servlet, it is passed to the container. What a container does with an exception differs, depending on the container vendor and the container's configuration, but by default a container usually tries to help by sending an error message followed by a stack trace to the client. Leaving a visitor with this type of page is not recommended if the client is valued.

Tomcat provides a good example of what type of page a user of a Web Application should never be allowed to see. If an exception happens to be thrown from either a JSP or Servlet, Tomcat automatically generates a simple error page. In case you don't know what this error page looks like, it can easily be found by throwing an unaccounted-for exception intentionally, as displayed in Listing 4-8.

Listing 4-8. ThrowException.jsp

<%
if (true)
 throw new Exception("An Exception foo!");
%>

Save ThrowException.jsp in the base directory of the jspbook Web Application and browse to http://127.0.0.1/jspbook/ThrowException.jsp. ThrowException.jsp throws an exception and lets Tomcat figure out what to do with it. Figure 4-3 shows a browser rendering of the Tomcat-generated debugging message.

Figure 4-3 is hideous! There are easy ways to make sure a Web Application never lets a client see a generated exception page. In addition to using try-catch-finally statements, JSP and Servlets define specific methods for effectively managing exceptions. There is no excuse not to use them, and they ensure a visitor is never left with a cryptic error page.

[ directory ]