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.
|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.|
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.
|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.|
Previous Chapter: Self Test - Chapters 20 to 24
Next Chapter: Chapter 26 - Returning Error Codes