[Django] #32113: No error at 404 page

4 views
Skip to first unread message

Django

unread,
Oct 16, 2020, 3:16:07 PM10/16/20
to django-...@googlegroups.com
#32113: No error at 404 page
-----------------------------------------+------------------------
Reporter: lcd1232 | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 3.1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
It's difficult to find a bug if page has no stack trace or readable error.
I caught this error if I do not return anything from the context
processor. It would be great if Django will add a readable error for this
situation.

If you have a custom 404 template and page not found then you got 500
error without understanding why.

Reproducible application -
https://gist.github.com/lcd1232/f242d88b1eaeaccbb6ba2e81e68644cd

One more example of a context processor that can generate the same error:

{{{
def url_info(request):
"""
Adds url info.
"""
info = resolve(request.path_info) # raised exception for 404 page
return {
"url_info": {
"app_name": info.namespace,
"url_name": info.url_name,
"full_name": f"{info.namespace}:{info.url_name}"
}
}
}}}

--
Ticket URL: <https://code.djangoproject.com/ticket/32113>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Oct 19, 2020, 8:28:04 AM10/19/20
to django-...@googlegroups.com
#32113: No error at 404 page when context processor returns None.
---------------------------------+--------------------------------------
Reporter: lcd1232 | Owner: nobody
Type: Bug | Status: closed
Component: Template system | Version: 3.1
Severity: Normal | Resolution: wontfix

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------

Comment (by lcd1232):

Ok. And what about adding this check for the system check framework?

--
Ticket URL: <https://code.djangoproject.com/ticket/32113#comment:2>

Django

unread,
Oct 19, 2020, 1:49:59 PM10/19/20
to django-...@googlegroups.com
#32113: No error at 404 page when context processor returns None.
---------------------------------+--------------------------------------
Reporter: lcd1232 | Owner: nobody

Type: Bug | Status: closed
Component: Template system | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------

Comment (by Mariusz Felisiak):

Replying to [comment:2 lcd1232]:


> Ok. And what about adding this check for the system check framework?

I'm against this, we cannot add a system check for any unsupported usage.
Also I'm not sure if it's doable, because a context processor can return
`None` only under certain circumstances. You can start a discussion on
DevelopersMailingList if you don't agree.

--
Ticket URL: <https://code.djangoproject.com/ticket/32113#comment:3>

Django

unread,
Sep 16, 2021, 9:34:01 AM9/16/21
to django-...@googlegroups.com
#32113: No error at 404 page when context processor returns None.
---------------------------------+--------------------------------------
Reporter: lcd1232 | Owner: nobody

Type: Bug | Status: closed
Component: Template system | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------

Comment (by Timothy Schilling):

The debug toolbar has hit this case a few times and it's a painful for the
maintainers to determine this is the reason the toolbar doesn't function.
Perhaps we can add more emphasis around the need to have to return a
dictionary? For example maybe adding a comment within the code example
that was introduced in v3.2 that says `# A dictionary must always be
returned`. This would be similar to how the form `clean_[field]`
[https://docs.djangoproject.com/en/3.2/ref/forms/validation/#cleaning-a
-specific-field-attribute documentation] informs developers about
returning the cleaned data.

--
Ticket URL: <https://code.djangoproject.com/ticket/32113#comment:4>

Reply all
Reply to author
Forward
0 new messages