(and apologies, (just after I hit send) I realized that I may be off mark, as I'm not working with 1.3/dev in my current apps... so I may be missing some critical changes in 1.3.)
On Dec 4, 9:15 am, Tim Diggins <[email protected]> wrote: > 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 <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
