Error Handling
=> Request Attributes
AWeb application must be able to specify that when errors occur. other resources in the application are used to provide the content body of the error response. The specification of these resources is done in the deployment descriptor.
If the location of the error handler is a servlet or a JSP page:
=> The original unwrapped request and response objects created by the container are passed to the servlet or JSP page.
=> The response setStatus method is disabled and ignored if called.
=> The request path and attributes are set as if a RequestDispatcher.forward to the error resource had been performed.
=> The request attributes in Table SRV.9-1 must be set.
Table : Request Attributes and their types
Request Attributes Type
javax.servlet.error.status_code java.lang.Integer
javax.servlet.error.exception_type java.lang.Class
javax.servlet.error.message java.lang.String
javax.servlet.error.exception java.lang.Throwable
javax.servlet.error.request_uri java.lang.String
javax.servlet.error.servlet_name java.lang.String
These attributes allow the servlet to generate specialized content depending on the status code, the exception type, the error message, the exception object propagated, and the URI of the request processed by the servlet in which the error occurred (as determined by the getRequestURI call), and the logical name of the
servlet in which the error occurred.
With the introduction of the exception object to the attributes list for version 2.3 of this specification, the exception type and error message attributes are redundant. They are retained for backwards compatibility with earlier versions of the API.
AWeb application must be able to specify that when errors occur. other resources in the application are used to provide the content body of the error response. The specification of these resources is done in the deployment descriptor.
If the location of the error handler is a servlet or a JSP page:
=> The original unwrapped request and response objects created by the container are passed to the servlet or JSP page.
=> The response setStatus method is disabled and ignored if called.
=> The request path and attributes are set as if a RequestDispatcher.forward to the error resource had been performed.
=> The request attributes in Table SRV.9-1 must be set.
Table : Request Attributes and their types
Request Attributes Type
javax.servlet.error.status_code java.lang.Integer
javax.servlet.error.exception_type java.lang.Class
javax.servlet.error.message java.lang.String
javax.servlet.error.exception java.lang.Throwable
javax.servlet.error.request_uri java.lang.String
javax.servlet.error.servlet_name java.lang.String
These attributes allow the servlet to generate specialized content depending on the status code, the exception type, the error message, the exception object propagated, and the URI of the request processed by the servlet in which the error occurred (as determined by the getRequestURI call), and the logical name of the
servlet in which the error occurred.
With the introduction of the exception object to the attributes list for version 2.3 of this specification, the exception type and error message attributes are redundant. They are retained for backwards compatibility with earlier versions of the API.
=> Error Pages
To allow developers to customize the appearance of content returned to aWeb client when a servlet generates an error, the deployment descriptor defines a list of error page descriptions. The syntax allows the configuration of resources to be returned by the container either when a servlet or filter calls sendError on the response for specific status codes, or if the servlet generates an exception or error that propagates to the container.
If the sendError method is called on the response, the container consults the list of error page declarations for the Web application that use the status-code syntax and attempts a match. If there is a match, the container returns the resource as indicated by the location entry.
A servlet or filter may throw the following exceptions during processing of a request:
=> runtime exceptions or errors
=> ServletExceptions or subclasses thereof
=> IOExceptions or subclasses thereof
The Web application may have declared error pages using the exceptiontype element. In this case the container matches the exception type by comparing the exception thrown with the list of error-page definitions that use the exception-type element. A match results in the container returning the resource
indicated in the location entry. The closest match in the class heirarchy wins.
If no error-page declaration containing an exception-type fits using the class-heirarchy match, and the exception thrown is a ServletException or subclass thereof, the container extracts the wrapped exception, as defined by the ServletException.getRootCause method. A second pass is made over the error page declarations, again attempting the match against the error page declarations, but using the wrapped exception instead.
Error-page declarations using the exception-type element in the deployment descriptor must be unique up to the class name of the exception-type. Similarly, error-page declarations using the status-code element must be unique in the deployment descriptor up to the status code.
The error page mechanism described does not intervene when errors occur when invoked using the RequestDispatcher or filter.doFilter method. In this way, a filter or servlet using the RequestDispatcher has the opportunity to handle errors generated.
If a servlet generates an error that is not handled by the error page mechanism as described above, the container must ensure to send a response with status 500.
The default servlet and container will use the sendError method to send 4xx and 5xx status responses, so that the error mechanism may be invoked. The default servlet and container will use the setStatus method for 2xx and 3xx responses and will not invoke the error page mechanism.
If the sendError method is called on the response, the container consults the list of error page declarations for the Web application that use the status-code syntax and attempts a match. If there is a match, the container returns the resource as indicated by the location entry.
A servlet or filter may throw the following exceptions during processing of a request:
=> runtime exceptions or errors
=> ServletExceptions or subclasses thereof
=> IOExceptions or subclasses thereof
The Web application may have declared error pages using the exceptiontype element. In this case the container matches the exception type by comparing the exception thrown with the list of error-page definitions that use the exception-type element. A match results in the container returning the resource
indicated in the location entry. The closest match in the class heirarchy wins.
If no error-page declaration containing an exception-type fits using the class-heirarchy match, and the exception thrown is a ServletException or subclass thereof, the container extracts the wrapped exception, as defined by the ServletException.getRootCause method. A second pass is made over the error page declarations, again attempting the match against the error page declarations, but using the wrapped exception instead.
Error-page declarations using the exception-type element in the deployment descriptor must be unique up to the class name of the exception-type. Similarly, error-page declarations using the status-code element must be unique in the deployment descriptor up to the status code.
The error page mechanism described does not intervene when errors occur when invoked using the RequestDispatcher or filter.doFilter method. In this way, a filter or servlet using the RequestDispatcher has the opportunity to handle errors generated.
If a servlet generates an error that is not handled by the error page mechanism as described above, the container must ensure to send a response with status 500.
The default servlet and container will use the sendError method to send 4xx and 5xx status responses, so that the error mechanism may be invoked. The default servlet and container will use the setStatus method for 2xx and 3xx responses and will not invoke the error page mechanism.
=> Error Filters
The error page mechanism operates on the original unwrapped/unfiltered request and response objects created by the container. The mechanism described in Section “Filters and the RequestDispatcher” may be used to specify filters that are applied before an error response is generated.
No comments:
Post a Comment