Yeah, I see the inconsistency there, and my first thought was that
this is a bit backward. However, the underlying distinction here is
that it's not the 404 (ie, the resource gone missin') that is the
exception but the Http404 object.
It remains straightforward enough for a developer to simply return
HttpResponseNotFound if they don't want their business logic treated
as an exception.
(Maybe this belongs on -dev) I do, however, think that the
get_object_or_404 documentation can be clearer that, as with .get(),
either failing case raises an exception. Perhaps change the note to:
"As with .get(), an exception is raised unless exactly one object is
found for the given parameters. A MultipleObjectsReturned exception
will be raised if more than one object is found. However, unlike
.get(), Http404 is raised if no object is found."
This may not be necessary at all, as the Http404 page makes it clear
that it's an exception.
On Wed, Mar 28, 2012 at 7:22 PM, Russell Keith-Magee
<russell@keith-magee.com> wrote:
>
>
> On 29/03/2012, at 12:10 AM, Justin Holmes wrote:
>
> > Russell,
> >
> > Thanks for the reply.
> >
> > Two reasons:
> >
> > 1) Up until now, I hadn't encountered a 404 that had triggered this particular process_exception. It hadn't occurred to me that since get_object_or_404 actually raises the Http404 exception that the behavior was going to be different than, say, a try block whose exception clause returned HttpResponseNotFound.
> >
> > 2) Once I had encountered this phenomenon, a quick google search led me to this page from the book:
> >
> > http://www.djangobook.com/en/beta/chapter16/
> >
> > ....which seemed, at least for a moment, to verify my previous experience.
>
> Yes - that does seem to suggest 404's don't trigger exception middleware. However, I've checked the code back to the magic-removal merge (in 2005) [1], and I can't see any evidence that 404's have ever been a special case.
>
> [1] https://code.djangoproject.com/browser/django/trunk/django/core/handlers/base.py?rev=2809#L73
>
> The only change to this area that I can see is to make sure that the response raised by the exception middleware is in recent times has been a modification that means that if the exception middleware returns a response, that response goes through the response middleware; back in the days of magic-removal, it would be returned verbatim.
>
> > I think though that I simply hadn't raised Http404 since implementing this middleware. It makes perfect sense that it behaves the way it does.
>
> Yes and no; yes, in that it's an exception; no, in that it's an interesting inconsistency that 404s are (or can be) handled as exceptions, but no other status code is handled as an exception.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
--
Justin Holmes
Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment