# HTTP Exceptions This module implements a number of Python exceptions you can raise fromwithin your views to trigger a standard non-200 response. ### Usage Example ~~~ from werkzeug.wrappers import BaseRequest from werkzeug.wsgi import responder from werkzeug.exceptions import HTTPException, NotFound def view(request): raise NotFound() @responder def application(environ, start_response): request = BaseRequest(environ) try: return view(request) except HTTPException as e: return e ~~~ As you can see from this example those exceptions are callable WSGIapplications. Because of Python 2.4 compatibility those do not extendfrom the response objects but only from the python exception class. As a matter of fact they are not Werkzeug response objects. However youcan get a response object by calling get_response() on a HTTPexception. Keep in mind that you have to pass an environment to get_response()because some errors fetch additional information from the WSGIenvironment. If you want to hook in a different exception page to say, a 404 statuscode, you can add a second except for a specific subclass of an error: ~~~ @responder def application(environ, start_response): request = BaseRequest(environ) try: return view(request) except NotFound, e: return not_found(request) except HTTPException, e: return e ~~~ ### Error Classes The following error classes exist in Werkzeug: *exception *werkzeug.exceptions.BadRequest(*description=None*, *response=None*) *400*Bad Request Raise if the browser sends something to the application the applicationor server cannot handle. *exception *werkzeug.exceptions.Unauthorized(*description=None*, *response=None*) *401*Unauthorized Raise if the user is not authorized. Also used if you want to use HTTPbasic auth. *exception *werkzeug.exceptions.Forbidden(*description=None*, *response=None*) *403*Forbidden Raise if the user doesn't have the permission for the requested resourcebut was authenticated. *exception *werkzeug.exceptions.NotFound(*description=None*, *response=None*) *404*Not Found Raise if a resource does not exist and never existed. *exception *werkzeug.exceptions.MethodNotAllowed(*valid_methods=None*, *description=None*) *405*Method Not Allowed Raise if the server used a method the resource does not handle. Forexample POST if the resource is view only. Especially useful for REST. The first argument for this exception should be a list of allowed methods.Strictly speaking the response would be invalid if you don't provide validmethods in the header which you can do with that list. *exception *werkzeug.exceptions.NotAcceptable(*description=None*, *response=None*) *406*Not Acceptable Raise if the server can't return any content conforming to theAccept headers of the client. *exception *werkzeug.exceptions.RequestTimeout(*description=None*, *response=None*) *408*Request Timeout Raise to signalize a timeout. *exception *werkzeug.exceptions.Conflict(*description=None*, *response=None*) *409*Conflict Raise to signal that a request cannot be completed because it conflictswith the current state on the server. 0.7 新版功能. *exception *werkzeug.exceptions.Gone(*description=None*, *response=None*) *410*Gone Raise if a resource existed previously and went away without new location. *exception *werkzeug.exceptions.LengthRequired(*description=None*, *response=None*) *411*Length Required Raise if the browser submitted data but no Content-Length header whichis required for the kind of processing the server does. *exception *werkzeug.exceptions.PreconditionFailed(*description=None*, *response=None*) *412*Precondition Failed Status code used in combination with If-Match, If-None-Match, orIf-Unmodified-Since. *exception *werkzeug.exceptions.RequestEntityTooLarge(*description=None*, *response=None*) *413*Request Entity Too Large The status code one should return if the data submitted exceeded a givenlimit. *exception *werkzeug.exceptions.RequestURITooLarge(*description=None*, *response=None*) *414*Request URI Too Large Like *413* but for too long URLs. *exception *werkzeug.exceptions.UnsupportedMediaType(*description=None*, *response=None*) *415*Unsupported Media Type The status code returned if the server is unable to handle the media typethe client transmitted. *exception *werkzeug.exceptions.RequestedRangeNotSatisfiable(*description=None*, *response=None*) *416*Requested Range Not Satisfiable The client asked for a part of the file that lies beyond the endof the file. 0.7 新版功能. *exception *werkzeug.exceptions.ExpectationFailed(*description=None*, *response=None*) *417*Expectation Failed The server cannot meet the requirements of the Expect request-header. 0.7 新版功能. *exception *werkzeug.exceptions.ImATeapot(*description=None*, *response=None*) *418*I'm a teapot The server should return this if it is a teapot and someone attemptedto brew coffee with it. 0.7 新版功能. *exception *werkzeug.exceptions.PreconditionRequired(*description=None*, *response=None*) *428*Precondition Required The server requires this request to be conditional, typically to preventthe lost update problem, which is a race condition between two or moreclients attempting to update a resource through PUT or DELETE. By requiringeach client to include a conditional header (“If-Match” or “If-Unmodified-Since”) with the proper value retained from a recent GET request, theserver ensures that each client has at least seen the previous revision ofthe resource. *exception *werkzeug.exceptions.TooManyRequests(*description=None*, *response=None*) *429*Too Many Requests The server is limiting the rate at which this user receives responses, andthis request exceeds that rate. (The server may use any convenient methodto identify users and their request rates). The server may include a“Retry-After” header to indicate how long the user should wait beforeretrying. *exception *werkzeug.exceptions.RequestHeaderFieldsTooLarge(*description=None*, *response=None*) *431*Request Header Fields Too Large The server refuses to process the request because the header fields are toolarge. One or more individual fields may be too large, or the set of allheaders is too large. *exception *werkzeug.exceptions.InternalServerError(*description=None*, *response=None*) *500*Internal Server Error Raise if an internal server error occurred. This is a good fallback if anunknown error occurred in the dispatcher. *exception *werkzeug.exceptions.NotImplemented(*description=None*, *response=None*) *501*Not Implemented Raise if the application does not support the action requested by thebrowser. *exception *werkzeug.exceptions.BadGateway(*description=None*, *response=None*) *502*Bad Gateway If you do proxying in your application you should return this status codeif you received an invalid response from the upstream server it accessedin attempting to fulfill the request. *exception *werkzeug.exceptions.ServiceUnavailable(*description=None*, *response=None*) *503*Service Unavailable Status code you should return if a service is temporarily unavailable. *exception *werkzeug.exceptions.HTTPUnicodeError This exception is used to signal unicode decode errors of requestdata. For more information see the [*Unicode*](#) chapter. *exception *werkzeug.exceptions.ClientDisconnected(*description=None*, *response=None*) Internal exception that is raised if Werkzeug detects a disconnectedclient. Since the client is already gone at that point attempting tosend the error message to the client might not work and might ultimatelyresult in another exception in the server. Mainly this is here so thatit is silenced by default as far as Werkzeug is concerned. Since disconnections cannot be reliably detected and are unspecifiedby WSGI to a large extend this might or might not be raised if a clientis gone. 0.8 新版功能. *exception *werkzeug.exceptions.SecurityError(*description=None*, *response=None*) Raised if something triggers a security error. This is otherwiseexactly like a bad request error. 0.9 新版功能. ### Baseclass All the exceptions implement this common interface: *exception *werkzeug.exceptions.HTTPException(*description=None*, *response=None*) Baseclass for all HTTP exceptions. This exception can be called as WSGIapplication to render a default error page or you can catch the subclassesof it independently and render nicer error messages. __call__(*environ*, *start_response*) Call the exception as WSGI application. <table class="docutils field-list" frame="void" rules="none"><col class="field-name"/><col class="field-body"/><tbody valign="top"><tr class="field-odd field"><th class="field-name">参数:</th><td class="field-body"><ul class="first last simple"><li><strong>environ</strong> – the WSGI environment.</li><li><strong>start_response</strong> – the response callable provided by the WSGIserver.</li></ul></td></tr></tbody></table> get_response(*environ=None*) Get a response object. If one was passed to the exceptionit's returned directly. | 参数: | **environ** – the optional environ for the request. Thiscan be used to modify the response dependingon how the request looked like. | |-----|-----| | 返回: | a Response object or a subclass thereof. | ### Special HTTP Exceptions Starting with Werkzeug 0.3 some of the builtin classes raise exceptions thatlook like regular python exceptions (eg [KeyError](http://docs.python.org/dev/library/exceptions.html#KeyError "(在 Python v3.5)") [http://docs.python.org/dev/library/exceptions.html#KeyError]) but are[BadRequest](# "werkzeug.exceptions.BadRequest") HTTP exceptions at the same time. This decision was madeto simplify a common pattern where you want to abort if the client tamperedwith the submitted form data in a way that the application can't recoverproperly and should abort with 400BADREQUEST. Assuming the application catches all HTTP exceptions and reacts to themproperly a view function could do the following savely and doesn't have tocheck if the keys exist: ~~~ def new_post(request): post = Post(title=request.form['title'], body=request.form['body']) post.save() return redirect(post.url) ~~~ If title or body are missing in the form a special key error will beraised which behaves like a [KeyError](http://docs.python.org/dev/library/exceptions.html#KeyError "(在 Python v3.5)") [http://docs.python.org/dev/library/exceptions.html#KeyError] but also a [BadRequest](# "werkzeug.exceptions.BadRequest")exception. ### Simple Aborting Sometimes it's convenient to just raise an exception by the error code,without importing the exception and looking up the name etc. For thispurpose there is the [abort()](# "werkzeug.exceptions.abort") function. werkzeug.exceptions.abort(*status*) It can be passed a WSGI application or a status code. If a status codeis given it's looked up in the list of exceptions from above and willraise that exception, if passed a WSGI application it will wrap it ina proxy WSGI exception and raise that: ~~~ abort(404) abort(Response('Hello World')) ~~~ If you want to use this functionality with custom exceptions you cancreate an instance of the aborter class: *class *werkzeug.exceptions.Aborter(*mapping=None*, *extra=None*) When passed a dict of code -> exception items it can be used ascallable that raises exceptions. If the first argument to thecallable is an integer it will be looked up in the mapping, if it'sa WSGI application it will be raised in a proxy exception. The rest of the arguments are forwarded to the exception constructor. ### Custom Errors As you can see from the list above not all status codes are available aserrors. Especially redirects and ather non 200 status codes thatrepresent do not represent errors are missing. For redirects you can usethe redirect() function from the utilities. If you want to add an error yourself you can subclass [HTTPException](# "werkzeug.exceptions.HTTPException"): ~~~ from werkzeug.exceptions import HTTPException class PaymentRequired(HTTPException): code = 402 description = '<p>Payment required.</p>' ~~~ This is the minimal code you need for your own exception. If you want toadd more logic to the errors you can override theget_description(), get_body(),get_headers() and [get_response()](# "werkzeug.exceptions.HTTPException.get_response")methods. In any case you should have a look at the sourcecode of theexceptions module. You can override the default description in the constructor with thedescription parameter (it's the first argument for all exceptionsexcept of the [MethodNotAllowed](# "werkzeug.exceptions.MethodNotAllowed") which accepts a list of allowed methodsas first argument): ~~~ raise BadRequest('Request failed because X was not present') ~~~