Exception handling in Servlet and JSP specifications


In the previous section, you looked at the general principles in exception handling without a J2EE tilt. In this section, we will cover what servlet specification has to say about exception handling. Consider the doGet() method signature in a HttpServlet .

 public void doGet(HttpServletRequest request,                       HttpServletResponse response) throws                       ServletException, IOException 

The above method signature implies that a Servlet or a JSP (and finally a web application) is only allowed to throw

  • ServletException or its subclasses

  • IOException or its subclasses

  • RuntimeExceptions

All other checked exceptions have to be handled in the Servlet/JSP code in one of the following manner:

  • Catch the checked exception and log the error message and (or) take any business related action.

  • Wrap the exception in a ServletException and throw the ServletException . ( ServletException has overloaded constructors to wrap the actual exception.)

Servlet specification provides exception-handling support through web.xml . In web.xml , you can declare < error-page > to handle exceptions that are thrown but not caught.

 <error-page>        <exception-type>UnhandledException</exception-type>        <location>UnhandledException.jsp</location>      </error-page> 

What this means is that if an exception of type UnhandledException is thrown from your web application but not caught anywhere , then the user gets to see the UnhandledException.jsp . This works well for ServletException , IOException , RuntimeException and their subclasses.

If the UnhandledException is a subclass of ServletException and none of the error-page declaration containing exception-type fit the class hierarchy of the thrown exception, then the Servlet container gets the wrapped exception using the ServletException.getRootCause method. Then the container attempts again to match the error-page declaration. This approach works well if the UnhandledException is not a subclass of ServletException or IOException (but is a checked exception). You have to throw a ServletException or its subclass by wrapping the UnhandledException in it and the servlet container does rest of the magic.

There are times when the user cannot see a page due to incorrect access rights or the page simply does not exist. The Servlet sends an error response with an appropriate HTTP error code. For instance, 404 corresponds to Page not found, 500 corresponds to Internal Server Error and so on. You can also assign JSPs for default HTTP error code as follows .

 <error-page>             <error-code>404</error-code>             <location>exceptions/Page404.jsp</location>           </error-page> 

Similarly, exceptions can occur in the JSPs in scriptlets and custom tags. These can throw runtime exceptions. In addition scriptlets can throw ServletException and IOException since a JSP gets translated into the body of _jspService() method and the signature of the _jspService() method is same as doGet() .

 public void _jspService(HttpServletRequest request,                       HttpServletResponse response) throws                       ServletException, IOException 

Tags however throw JspException in their tag callback methods ( doStartTag() , doEndTag() and so on). JspException is a direct subclass of java.lang.Exception and has no relationship with ServletException or IOException . The _jspService() method is container dependent but its contract is to catch all those exceptions and forward the request to the errorPage specified by the JSP. Hence it is a best practice to assign error pages in JSPs with the declarative: < %@ page errorPage="/error.jsp" % >

When forwarding to the exception page as specified by errorPage setting shown above, the exception describing the error is stored as request attribute with the key ‚“ javax.servlet.jsp.JspException ‚½. If the JSP assigned to handle the exceptions has the directive < %@ page isErrorPage="true" % > at the top of their page, then the exception is provided as the implicit scripting variable named exception .




Struts Survival Guide. Basics to Best Practices
Struts Survival Guide: Basics to Best Practices (J2ee Survival Series)
ISBN: 0974848808
EAN: 2147483647
Year: 2004
Pages: 96

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net