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:

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.

The server requires this request to be conditional, typically to prevent
the lost update problem, which is a race condition between two or more
clients attempting to update a resource through PUT or DELETE. By requiring
each client to include a conditional header (“If-Match” or “If-Unmodified-
Since”) with the proper value retained from a recent GET request, the
server ensures that each client has at least seen the previous revision of
the resource.

The server is limiting the rate at which this user receives responses, and
this request exceeds that rate. (The server may use any convenient method
to identify users and their request rates). The server may include a
“Retry-After” header to indicate how long the user should wait before
retrying.

Internal exception that is raised if Werkzeug detects a disconnected
client. Since the client is already gone at that point attempting to
send the error message to the client might not work and might ultimately
result in another exception in the server. Mainly this is here so that
it is silenced by default as far as Werkzeug is concerned.

Since disconnections cannot be reliably detected and are unspecified
by WSGI to a large extent this might or might not be raised if a client
is gone.

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 400BADREQUEST.

Assuming the application catches all HTTP exceptions and reacts to them
properly a view function could do the following safely and doesn’t have to
check if the keys exist:

Raises an HTTPException for the given status code or WSGI
application:

abort(404)# 404 Not Foundabort(Response('Hello World'))

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 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 exceptions you can
create an instance of the aborter class:

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 an integer it will be looked up in the mapping, if it’s
a WSGI application it will be raised in a proxy exception.

As you can see from the list above not all status codes are available as
errors. Especially redirects and other non 200 status codes that do not
represent errors are missing. For redirects you can use the redirect()
function from the utilities.

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):