Monday, March 28, 2011

Chapter 25: Introduction to Servlet Exception Handling

Any technology, any programming language you learn, exception handling is an integral part of it. And the SCWCD exam covers topics related to Exception Handling in the Servlet Technology as well. Though, there are numerous ways of customized error handling available with servlets, the exam covers two main topics. Using the SENDERROR and SETSTATUS.

That is exactly what we are going to learn in this chapter and the next few chapters too.

So, lets get started!!!

Introduction to Servlet Exception Handling:

The way in which you create and manage exceptions in servlets is slightly different from how you do this with standalone applications.

We always use the response object (HttpServletResponse) and not the request object, to tell the browser that there is a problem.

The exam includes both exceptions (The ones caused by the Servlet) and HTTP Error Codes (Those you send back to the client).

Before we jump into the world of exceptions, lets quickly review the HTTP Protocol standards. This is essential because, the servlets communicate with clients using HTTP and it is helpful to know a little about this protocol.

The HTTP Protocol:

The HTTP protocol is a request/response scheme where a client sends a request to the server. There are four major portions of this request, which include, a request method (GET, POST…), URI (such as, protocol version (HTTP/1.1), and finally a MIME-like message. This message can be any size, and normally includes request modifiers, client information, and body content.

In this series of chapters, we will learn how we can send error information to the client using the sendError method, which sends a status line with the protocol version and a success or error code. It also returns a MIME like message containing server information, entity meta information and body content. You must remember that both the severity and type of error to properly tell the client what went wrong. Your error handling logic needs to determine the most appropriate severity for a particular error.

After receiving a request, the server responds. It returns an HTTP response message. The first line of this response message is called the status line. The status line has three parts. They are, in this order, protocol version, numeric status code, and status textual phrase. This status code is what you are setting when you use sendError and setStatus methods.

The Error Codes:

If you have been using the internet and J2EE applications for a while, you are sure to have encountered the 404: PAGE NOT FOUND message at some websites. This tells you that the URL is bad. i.e., if you try login to you will probably get this message. The emphasis is on the number 404, this is the status code, a 3 digit integer number. The first digit defines the class of response, while the last two digits do not have any categories; they give an indication of what the problem is.

Let us now take a look at all the error codes that we can encounter in a HTTP based J2EE system. This list just contains the broad categorization based on the 1st digit.

Number Type Description
1XX Informational Request received, continuing to process.
2XX Success The action was successfully received, understood, and accepted.
3XX Redirection Further action must be taken in order to complete the request.
4XX Client Error The request contains bad syntax or cannot be fulfilled.
5XX Server Error The server failed to fulfill an apparently valid request.
While, the above table describes five set of status codes, we will primarily focus on the Server Error Category – the 5XX codes.

As mentioned previously, the HTTP protocol is a request/response scheme where a client sends a request to the server. When you need to inform the client of a problem at the server end, you call the sendError method. This causes the server to respond with a status line, with protocol version and a success or error code (this is what sendError affects directly). Of course, it also returns a MIME-like message containing server information, entity meta information, and body content.

Actually, the sendError() and setStatus are closely related. In fact, they both set the error message to be displayed by the client and the status code used by the client. The default status code is HttpServletResponse.SC_OK ="OK"; however, there are a few other standard codes as well.
That being said, lets take a look at the list of status codes available. These codes were defined by the W3C and are sanctioned by the Internet Society (ISOC). The constant names, quoted messages that get displayed in the browser, and code descriptions are a combination of the servlet specification and Tomcat's implementation of that specification. The exam will not test your memory of these directly. However, taking five minutes to study this table will help you understand what these codes do and figure out which ones you need to use with the sendError and setStatus methods. Notice that the RFC column provides the Request For Comment document and section, the Internet's way of documenting standards. Also, some browsers allow the user to hide “friendly” error messages. If they do that, they will not see many of these errors, even if they occur.

Code Constant RFC Message Description
100 SC_CONTINUE 10.1.1 “Continue” Client can continue.
101 SC_SWITCHING_PROTOCOLS 10.1.2 “Switching Protocols” Server is switching protocols according to Upgrade header.
200 SC_OK 10.2.1 “OK” Request succeeded normally.
201 SC_CREATED 10.2.2 “Created” Request succeeded and created a new resource on the server.
202 SC_ACCEPTED 10.2.3 “Accepted” Request was accepted for processing but was not completed.
203 SC_NON_AUTHORITATIVE_INFORMATION 10.2.4 “Non-Authoritative Information” Meta information presented by the client did not originate from the server.
204 SC_NO_CONTENT 10.2.5 “No Content” Request succeeded but there was no new information to return.
205 SC_RESET_CONTENT 10.2.6 “Reset Content” Agent should reset the document view which caused the request to be sent.
206 SC_PARTIAL_CONTENT 10.2.7 “Partial Content” Server has fulfilled the partial GET request for the resource.
300 SC_MULTIPLE_CHOICES 10.3.1 “Multiple Choices” Requested resource corresponds to any one of a set of representations with each with its own specific location.
301 SC_MOVED_PERMANENTLY 10.3.2 “Moved Permanently” Resource has permanently moved to a new location and future references should use a new URI with their requests.
302 SC_MOVED_TEMPORARILY 10.3.3 “Moved Temporarily” Resource has temporarily moved to another location but future references should still use the original URI to access the resource.
303 SC_SEE_OTHER 10.3.4 “See Other” Response to the request can be found under a different URI.
304 SC_NOT_MODIFIED 10.3.5 “Not Modified” Conditional GET operation found that the resource was available and not modified.
305 SC_USE_PROXY 10.3.6 “Use Proxy” Requested resource must be accessed through the proxy given by the Location field.
307 SC_TEMPORARY_REDIRECT 10.3.8 N/A Requested resource resides temporarily under a different URI. The temporary URI should be given by the Location field in the response.
400 SC_BAD_REQUEST 10.4.1 “Bad Request” Request sent by the client was syntactically incorrect.
401 SC_UNAUTHORIZED 10.4.2 “Unauthorized” Request requires HTTP authentication.
402 SC_PAYMENT_REQUIRED 10.4.3 “Payment Required” Reserved for future use.
403 SC_FORBIDDEN 10.4.4 “Forbidden” Server understood the request but refused to fulfill it.
404 SC_NOT_FOUND 10.4.5 “Not Found” Requested resource is not available.
405 SC_METHOD_NOT_ALLOWED 10.4.6 “Method Not Allowed” Method specified in the Request-Line is not allowed for the resource identified by the Request-URI.
406 SC_NOT_ACCEPTABLE 10.4.7 “Not Acceptable” Resource identified by the request is only capable of generating response entities that have content characteristics not acceptable according to the accept headers sent in the request.
407 SC_PROXY_AUTHENTICATION_REQUIRED 10.4.8 “Proxy Authentication Required” Client must first authenticate itself with the proxy.
408 SC_REQUEST_TIMEOUT 10.4.9 “Request Timeout” Client did not produce a request within the time that the server was prepared to wait.
409 SC_CONFLICT 10.4.10 “Conflict” Request could not be completed due to a conflict with the current state of the resource.
410 SC_GONE 10.4.11 “Gone” Resource is no longer available at the server and no forwarding address is known. This condition should be considered permanent.
411 SC_LENGTH_REQUIRED 10.4.12 “Length Required” Request cannot be handled without a defined Content-Length.
412 SC_PRECONDITION_FAILED 10.4.13 “Precondition Failed” A precondition given in one or more of the request-header fields evaluated to false when it was tested on the server.
413 SC_REQUEST_ENTITY_TOO_LARGE 10.4.14 “Request Entity Too Large” Server is refusing to process the request because the request entity is larger than the server is willing or able to process.
414 SC_REQUEST_URI_TOO_LONG 10.4.15 “Request URI Too Long” Server is refusing to service the request because the Request-URI is longer than the server is willing to interpret.
415 SC_UNSUPPORTED_MEDIA_TYPE 10.4.16 “Unsupported Media Type” Server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.
416 SC_REQUESTED_RANGE_NOT_SATISFIABLE 10.4.17 “Requested Range Not Satisfiable” Server cannot serve the requested byte range.
417 SC_EXPECTATION_FAILED 10.4.18 “Expectation Failed” Server could not meet the expectation given in the Expect request header.
500 SC_INTERNAL_SERVER_ERROR 10.5.1 “Internal Server Error” Error inside the server which prevented it from fulfilling the request. This error represents many server problems such as exceptions or perhaps a database hiccup.
501 SC_NOT_IMPLEMENTED 10.5.2 “Not Implemented” Server does not support the functionality needed to fulfill the request.
502 SC_BAD_GATEWAY 10.5.3 “Bad Gateway” Server received an invalid response from a server it consulted when acting as a proxy or gateway.
503 SC_SERVICE_UNAVAILABLE 10.5.4 “Service Unavailable” Server is temporarily overloaded and unable to handle the request.
504 SC_GATEWAY_TIMEOUT 10.5.5 “Gateway Timeout” Server did not receive a timely response from the upstream server while acting as a gateway or proxy.
505 SC_HTTP_VERSION_NOT_SUPPORTED 10.5.6 “HTTP Version Not Supported” Server does not support or refuses to support the HTTP protocol version that was used in the request message.
Let me repeat, you need not memorize these status codes but knowing them would be useful to understand the servlet exception handling concepts.

Previous Chapter: Self Test - Chapters 20 to 24

Next Chapter: Chapter 26 - Returning Error Codes


  1. Really very nice. i impressed in just few minutes. Please carry on this journey

  2. Really nice and easy to understand vocabulary.. thanx alot


© 2013 by All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.