Context Navigation

← Previous Ticket
Next Ticket →

#24143 closed Cleanup/optimization (fixed)

Documentation uses uninstantiated Http404s

Reported by:	Keryn Knight	Owned by:	nobody
Component:	Documentation	Version:	dev
Severity:	Normal	Keywords:
Cc:	django@…	Triage Stage:	Ready for checkin
Has patch:	yes	Needs documentation:	no
Needs tests:	no	Patch needs improvement:	no
Easy pickings:	no	UI/UX:	no

Description

I've always used instantiated Http404 exceptions in my stuff, but it doesn't seem to be a well-defined practice, and isn't the demonstrated way in the documentation.

In DEBUG, when an Http404 is encountered it is re-routed to the 404 handler, which renders using TECHNICAL_404_TEMPLATE, and an opportunity arises to provide hints about what code was causing the error, much like I asked for in #22756 (if there's a theme to my tickets, it's that I value debugging simplicity), which puts the view causing the 404 into the result. By suggesting instantiating 404s with messages, we can help users help themselves further.

Given this view:

def myview(request, obj_id):
    obj = get_object_or_404(MyModel, pk=obj_id)
    if not mymodel.published:
        Http404("Unpublished")
    if not mymodel.is_accessible_via(request.method):
        Http404("Not via this method")
    if not mymodel.allows_user(request.user):
        Http404("Not found for this user")
    # ...

It is easy to see which 404 was thrown in the technical debug view because force_bytes is called on the exception (which inherits __str__ from Exception) and the reason is rendered as the error message if no urlpatterns were tried.

Without instantiating (raise Http404 vs raise Http404('message')) it becomes a debugging guessing game as to which condition threw the exception (ignoring the merit of the above conditions, which are total garbage)

I'm suggesting that the places in the documentation where bare, un-instantiated Http404s are raised is updated to reflect this idea, which is already used in places like get_object_or_404 anyway.