This sounds good to me, but can I give an additional or alternative
exception handling, for consideration (feels a bit simpler, both to
use and to implement):
Exceptions:
When catching an exception in BaseHandler.get_response look for a
"status_code" attribute (getattr(e, 'status_code', 500)) then do some
processing and pass exception on to view. Retrofit Http404
appropriately (but maybe keep the shortcut handling of Http404
itself...)
You can send the handle_uncaught_exception signal for any exception
that had no status_code attribute (or maybe even if it had a
status_code of 500)
View & template:
look for a handle{{status_code}} variable, falling back to
handle_exception. The generic handle_exception in non-DEBUG looks for
a specific "{{status_code}}.html" template, but falls back to a (say)
"http_exception.html" template. (there would be a very basic
implementation of this template supplied with django).
Debug:
In DEBUG==True, I'm not sure how important it is to allow the view
handlers differently per status_code (other than 404), but you could
do a similar lookup (technical_{{status_code}}_response) with 500 as
the fallback.
This strikes me as fairly expressive and not too magical, while being
quite lightweight, and (bonus) wouldn't require any deprecation.
(Sorry, I know you asked for crit, and I gave an alternative... It's
not that I thought that your plan was __wrong__, just that it was a
little heavier than needed).
Specific crit: I'm not keen on the HttpNotFound rename of Http404 --
Http404 is so easy to remember (and type) and somehow more expressive
(it stands out from surrounding code as being quite different, which
in fact it is).
Tim
On Dec 3, 2: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.)
>
> Andrew
--
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.
