id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
24143	Documentation uses uninstantiated Http404s	Keryn Knight	nobody	"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. "	Cleanup/optimization	closed	Documentation	dev	Normal	fixed		django@…	Ready for checkin	1	0	0	0	0	0