On Fri, Dec 3, 2010 at 10:36 PM, Andrew Godwin <and...@aeracode.org> wrote:
> So, one of the complaints I've heard from a few people now is the fact
> that 404 is the only thing one can raise as a HTTP error - there are
> plenty of others, such as 403 and 405, that could be useful to raise
> back to the client.
>
> This didn't used to be much of a problem with function-based views - you
> could just return a custom HTTPResponse - but now we have class-based
> views that's not always possible from every function (as some functions
> return intermediary values, and returning a HTTPResponse there isn't
> going to help).
>
> In the interim, I can use something which catches custom exceptions in
> my dispatch()/GET()/etc functions, but I'd like to propose that we
> extend core Django to allow for all the major HTTP error status codes to
> be raised as exceptions. I have a rough plan of how this would work:
>
> - Modify the base handler to catch a general exception base class
> rather than the special-case of Http404 and exceptions.PermissionDenied
>
> - Write this new base HttpException class that knows how to serve its
> own errors. By default, make it serve the template <error_code>.html (to
> replicate the old handler404 and handler500 behaviour). People can
> override these classes to change their template/view behaviour, and
> configure Django to use them as specified below.
>
> - Modify Http404 to use this new base class, and also implement the
> technical 404 response if debug mode is on. Also rename to HttpNotFound,
> but keep the old name for backwards-compatability.
>
> - Modify the exception-catching code to raise a HttpInternalServerError
> with the right attributes. HttpInternalServerError will then implement
> the technical 500 response.
>
> - Provide a whole range of other base exceptions (e.g. HttpForbidden).
>
> - Start handler404 and handler500 on a deprecation path, and replace
> them with a configuration dictionary HTTP_EXCEPTION_CLASSES =
> {status_code: "path.to.class"}.
>
> Obviously this is a bit late for 1.3, but if people are amenable to it
> I've got a few changes I can start on a branch already. We keep running
> into this at /dev/fort and in my own personal projects, and I figured it
> was better to ask people while the idea was fresh in my mind.
>
> (Also note the above implementation plan is very rough. Criticism of it
> is very welcome.)
This proposal has come up before and has historically been rejected;
however, your point about class-based views makes it a lot harder to
give the standard responses.
I've only got one piece of feedback, regarding the
HTTP_EXCEPTION_CLASSES idea. I can see two problems with this:
* Using a single system setting means that you can't install custom
handlers on a per-URLPattern basis, which is currently possible with
handler404/500
* To me, it would make more sense to implement HTTP_EXCEPTION_CLASSES
as a stack of instances, rather than as a 500->, 404->, 403-> dispatch
mechanism. My reasoning for this is that it seems to me that one of
the most common patterns would be to write a single exception handling
class, containing all the handler methods, and 'just install the damn
thing'. As you've proposed it, I'd need to install the same class in
(potentially) 5 or six locations.
This isn't so much of a problem at the moment because there's only two
handlers, and they aren't combined into a single class, but if we're
moving to needing handlers for all the different exception types, this
could get onerous. Using 'hasattr('handle404')' on a stack of
exception handling class instances feels like it would be a more
natural interface for this sort of thing.
However -- as you note -- I don't think this needs to be rushed as a
1.3 thing. There is something to be said for letting the dust settle
on the 1.3 CBV API to see where the holes are, and fixing them in the
1.4 cycle.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
