Opened 9 years ago

Last modified 2 months ago

#22055 new Cleanup/optimization

404 page does not display stack trace when Resolver404 is raised from a view

Reported by: Grzegorz Nosek Owned by:
Component: Core (URLs) Version: 1.6
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Related to #18373, the 404 error page served when django.core.urlresolvers.resolve() fails does not contain the exception stack trace, which makes finding the failing call unnecessarily difficult.

When the resolve() call fails in a view, the error should actually be 500 (it's not the user's fault), but for backwards compatibility the response code will have to remain 404 (as discussed with Honza Kral last year).

Change History (7)

comment:1 Changed 9 years ago by Grzegorz Nosek

Owner: changed from nobody to Grzegorz Nosek
Status: newassigned

comment:2 Changed 9 years ago by AeroNotix


What kind of useful information could you gain from a 404 page with a stacktrace? If you're explicitly creating a 404 exception then you want that to happen.

Could you convince this list of the usefulness in changing this behaviour, please?

comment:3 Changed 9 years ago by AeroNotix

Resolution: wontfix
Status: assignedclosed

comment:4 Changed 9 years ago by Grzegorz Nosek

Resolution: wontfix
Status: closednew

See #18373 for the use case.

If you're calling resolve('/some-url') that fails, you're not raising an Http404 explicitly. It's just a function call that fails, just like the ORM or whatever.

I agree that manually raised Http404s should not trigger the stack trace and this ticket is not about it. It's just about treating exceptions from resolve() failure just like every other exception.

IMO, the right thing to do is:

  • Failing to resolve a URL from Django core -> no stack trace
  • Raising Http404 from a view -> no stack trace
  • Failing to resolve a URL from a view -> stack trace (and arguably 500 response code but there's backwards compatibility to worry about)
Last edited 6 years ago by Anton Samarchyan (previous) (diff)

comment:5 Changed 9 years ago by Aymeric Augustin

Triage Stage: UnreviewedAccepted
Type: UncategorizedCleanup/optimization

comment:6 Changed 2 months ago by Mariusz Felisiak

Owner: Grzegorz Nosek deleted
Status: newassigned

comment:7 Changed 2 months ago by Mariusz Felisiak

Status: assignednew
Note: See TracTickets for help on using tickets.
Back to Top