# Werkzeug

# HTTP Exceptions

This module implements a number of Python exceptions you can raise from within your views to trigger a standard non-200 response.

## Usage Example

    from werkzeug import BaseRequest, 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, e:
            return e

As you can see from this example those exceptions are callable WSGI applications. Because of Python 2.4 compatibility those do not extend from the response objects but only from the python exception class.

As a matter of fact they are not Werkzeug response objects. However you can get a response object by calling `get_response()` on a HTTP exception.

Keep in mind that you have to pass an environment to `get_response()` because some errors fetch additional information from the WSGI environment.

If you want to hook in a different exception page to say, a 404 status code, 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)

  400 Bad Request

  Raise if the browser sends something to the application the application or server cannot handle.

exception `werkzeug.exceptions.``Unauthorized`(description=None)

  401 Unauthorized

  Raise if the user is not authorized. Also used if you want to use HTTP basic auth.

exception `werkzeug.exceptions.``Forbidden`(description=None)

  403 Forbidden

  Raise if the user doesn’t have the permission for the requested resource but was authenticated.

exception `werkzeug.exceptions.``NotFound`(description=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. For example 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 valid methods in the header which you can do with that list.

exception `werkzeug.exceptions.``NotAcceptable`(description=None)

  406 Not Acceptable

  Raise if the server can’t return any content conforming to the Accept headers of the client.

exception `werkzeug.exceptions.``RequestTimeout`(description=None)

  408 Request Timeout

  Raise to signalize a timeout.

exception `werkzeug.exceptions.``Gone`(description=None)

  410 Gone

  Raise if a resource existed previously and went away without new location.

exception `werkzeug.exceptions.``LengthRequired`(description=None)

  411 Length Required

  Raise if the browser submitted data but no `Content-Length` header which is required for the kind of processing the server does.

exception `werkzeug.exceptions.``PreconditionFailed`(description=None)

  412 Precondition Failed

  Status code used in combination with `If-Match`, `If-None-Match`, or `If-Unmodified-Since`.

exception `werkzeug.exceptions.``RequestEntityTooLarge`(description=None)

  413 Request Entity Too Large

  The status code one should return if the data submitted exceeded a given limit.

exception `werkzeug.exceptions.``RequestURITooLarge`(description=None)

  414 Request URI Too Large

  Like 413 but for too long URLs.

exception `werkzeug.exceptions.``UnsupportedMediaType`(description=None)

  415 Unsupported Media Type

  The status code returned if the server is unable to handle the media type the client transmitted.

exception `werkzeug.exceptions.``InternalServerError`(description=None)

  500 Internal Server Error

  Raise if an internal server error occurred. This is a good fallback if an unknown error occurred in the dispatcher.

exception `werkzeug.exceptions.``NotImplemented`(description=None)

  501 Not Implemented

  Raise if the application does not support the action requested by the browser.

exception `werkzeug.exceptions.``BadGateway`(description=None)

  502 Bad Gateway

  If you do proxying in your application you should return this status code if you received an invalid response from the upstream server it accessed in attempting to fulfill the request.

exception `werkzeug.exceptions.``ServiceUnavailable`(description=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 request data. For more information see the Unicode chapter.

## Baseclass

All the exceptions implement this common interface:

exception `werkzeug.exceptions.``HTTPException`(description=None)

  Baseclass for all HTTP exceptions. This exception can be called as WSGI application to render a default error page or you can catch the subclasses of it independently and render nicer error messages.

  `get_response`(environ)

    Get a response object.

    Parameter: | environ – the environ for the request.
    Returns: | a `BaseResponse` object or a subclass thereof.

  `__call__`(environ, start_response)

    Call the exception as WSGI application.

    Parameters: | environ – the WSGI environment. start_response – the response callable provided by the WSGI server.

## Special HTTP Exceptions

Starting with Werkzeug 0.3 some of the builtin classes raise exceptions that look like regular python exceptions (eg `KeyError`) but are `BadRequest` HTTP exceptions at the same time. This decision was made to simplify a common pattern where you want to abort if the client tampered with the submitted form data in a way that the application can’t recover properly and should abort with `400 BAD REQUEST`.

Assuming the application catches all HTTP exceptions and reacts to them properly a view function could do the following savely and doesn’t have to check 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 be raised which behaves like a `KeyError` but also a `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 this purpose there is the `abort` function.

It can be passed a WSGI application or a status code. If a status code is given it’s looked up in the list of exceptions from above and will raise that exception, if passed a WSGI application it will wrap it in a proxy WSGI exception and raise that:

    abort(404)
    abort(Response('Hello World'))

If you want to use this functionality with custom excetions you can create 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 as callable that raises exceptions. If the first argument to the callable is a integer it will be looked up in the mapping, if it’s a 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 as errors. Especially redirects and ather non 200 status codes that represent do not represent errors are missing. For redirects you can use the `redirect` function from the utilities.

If you want to add an error yourself you can subclass `HTTPException`:

    from werkzeug.exceptions import HTTPException

    class PaymentRequred(HTTPException):
        code = 402
        description = '<p>Payment required.</p>'

This is the minimal code you need for your own exception. If you want to add more logic to the errors you can override the `get_description`, `get_body`, `get_headers` and `get_response` methods. In any case you should have a look at the sourcecode of the exceptions module.

You can override the default description in the constructor with the description parameter (it’s the first argument for all exceptions except of the `MethodNotAllowed` which accepts a list of allowed methods as first argument):

    raise BadRequest('Request failed because X was not present')