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 www.abc.com), 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 www.thisissurelyanincorrectwebsite.com 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