|1600 PMP mock questions||1400 CAPM mock questions||800 SCJP 6 mock questions||600 OCAJP 7 mock questions||590 OCPJP 7 mock questions||556 SCWCD 5 mock questions||500 OCEJWCD 6 mock questions||pdfDownload (java,struts, hibernet etc)||JobsJobs and Walkins|
Servlet interview questions
!!! Servlet interview questions !!!
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
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
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.
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.
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
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.
Suggested JobsMore Jobs >>