[Django] #32997: Errors in 404 templates are hard to debug
Django
-------------------------------------------+------------------------
Reporter: jooadam | Owner: (none)
Type: Bug | Status: new
Component: Error reporting | Version: 3.2
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 |
-------------------------------------------+------------------------
I have a custom 404.html template, which extends a fairly complex base
template. Something in this base template raises an error when visiting a
non-existing page, but in DEBUG=True the page never gets rendered, and in
DEBUG=False I only see the 500 error page and the email sent to the ADMINS
address, which ''does not include a stack trace'', or rather, has None
listed under the stack trace.
I have no idea how to proceed with debugging, short of removing and adding
back dynamic statement and expression in my base template.
--
Ticket URL: <https://code.djangoproject.com/ticket/32997>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: jooadam | Owner: (none)
Type: Bug | Status: new
Component: Error reporting | Version: 3.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by jooadam:
Old description:
> I have a custom 404.html template, which extends a fairly complex base
> template. Something in this base template raises an error when visiting a
> non-existing page, but in DEBUG=True the page never gets rendered, and in
> DEBUG=False I only see the 500 error page and the email sent to the
> ADMINS address, which ''does not include a stack trace'', or rather, has
> None listed under the stack trace.
>
> I have no idea how to proceed with debugging, short of removing and
> adding back dynamic statement and expression in my base template.
New description:
I have a custom 404.html template, which extends a fairly complex base
template. Something in this base template raises an error when visiting a
non-existing page, but in DEBUG=True the page never gets rendered, and in
DEBUG=False I only see the 500 error page and the email sent to the ADMINS
address, which ''does not include a stack trace'', or rather, has None
listed under the stack trace.
I have no idea how to proceed with debugging, short of removing and adding
back every single dynamic statement and expression in my base template.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32997#comment:1>
Django
Reporter: jooadam | Owner: (none)
Type: Bug | Status: closed
Component: Error reporting | Version: 3.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => invalid
Comment:
It looks like you're asking for help with debugging. Trac is not a support
channel. Please see TicketClosingReasons/UseSupportChannels for ways to
get help.
--
Ticket URL: <https://code.djangoproject.com/ticket/32997#comment:2>
Django
Reporter: jooadam | Owner: (none)
Type: Bug | Status: closed
Component: Error reporting | Version: 3.2
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 jooadam):
Replying to [comment:2 Mariusz Felisiak]:
> It looks like you're asking for help with debugging. Trac is not a
support channel. Please see TicketClosingReasons/UseSupportChannels for
ways to get help.
Mariusz, can you please explain to me how is an error in a template
resulting in an 500 error not having a stack trace included in the email
report not a bug? I have already found the issue in my code, so at this
point I’m solely trying to make Django better by making the effort
reporting it. I would expect you to take it a little more seriously.
--
Ticket URL: <https://code.djangoproject.com/ticket/32997#comment:3>
Django
Reporter: jooadam | Owner: (none)
Type: Bug | Status: closed
Component: Error reporting | Version: 3.2
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):
> Mariusz, can you please explain to me how is an error in a template
resulting in an 500 error not having a stack trace included in the email
report not a bug?
I cannot because you have not explained the issue in enough detail to
confirm a bug in Django. Please reopen the ticket if you can debug your
issue and provide details about why and where Django is at fault.
--
Ticket URL: <https://code.djangoproject.com/ticket/32997#comment:4>
Django
Reporter: jooadam | Owner: (none)
Type: Bug | Status: closed
Component: Error reporting | Version: 3.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jooadam):
* Attachment "404-error.zip" added.
Django
Reporter: jooadam | Owner: (none)
Type: Bug | Status: closed
Component: Error reporting | Version: 3.2
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 jooadam):
Replying to [comment:4 Mariusz Felisiak]:
> I cannot because you have not explained the issue in enough detail to
confirm a bug in Django. Please reopen the ticket if you can debug your
issue and provide details about why and where Django is at fault.
I explained the issue in the exact detail you would have needed to
reproduce it: a 404.html with an error in production mode. See the
attachment.
--
Ticket URL: <https://code.djangoproject.com/ticket/32997#comment:5>
Django
Reporter: jooadam | Owner: (none)
Type: Bug | Status: new
Component: Error reporting | Version: 3.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jooadam):
* status: closed => new
* resolution: invalid =>
--
Ticket URL: <https://code.djangoproject.com/ticket/32997#comment:6>
Django
Reporter: jooadam | Owner: (none)
Type: Bug | Status: closed
Component: Error reporting | Version: 3.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => wontfix
Comment:
Hi. Thanks for the extra info.
> I have a custom 404.html template...
So custom error templates should (in general) be entirely straight-
forward, in order to be certain not to raise an error themselves.
(Adding complexity to the default error handlers here isn't something we
want to get into.)
In your case, where you want a more complex template, it's incumbent upon
you to also
[https://docs.djangoproject.com/en/3.2/topics/http/views/#s-id1 customise
the error views] to ensure any possible exceptions are appropriately dealt
with.
Minimally, you could add logging if you introduce the possibility of an
exception:
{{{
import logging
from django.views.defaults import page_not_found
logger = logging.getLogger(__name__)
def custom_page_not_found(request, exception, template_name='404.html'):
try:
page_not_found(request, exception, template_name)
except:
logger.exception("ERROR OCCURRED")
raise
handler404 = 'foo.urls.custom_page_not_found'
}}}
Your traceback is then available.
See also the [https://docs.djangoproject.com/en/3.2/topics/http/views
/#testing-custom-error-views Testing custom error views] section, that
will enable you to make sure your error handling works before putting it
live.
--
Ticket URL: <https://code.djangoproject.com/ticket/32997#comment:7>