Opened 9 years ago

Closed 4 years ago

Last modified 15 months ago

#6379 closed Bug (needsinfo)

Don't hide errors when resolving URL views

Reported by: Bastian Kleineidam <calvin@…> Owned by: nobody
Component: Core (Other) Version: master
Severity: Normal Keywords:
Cc: hv@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


The URL resolver catches _all_ attribute and import errors. This has the affect of hiding unrelated import errors in other parts of the (view) code which made it very hard for me to track them down.

This patch only catches the "missing view function" attribute error, and "unable to import view function" import error. All other errors are reraised.

Attachments (1)

no_exception_hiding.diff (1.0 KB) - added by Bastian Kleineidam <calvin@…> 9 years ago.

Download all attachments as: .zip

Change History (13)

Changed 9 years ago by Bastian Kleineidam <calvin@…>

comment:1 Changed 9 years ago by Bastian Kleineidam <calvin@…>

  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 9 years ago by Simon Greenhill <dev@…>

  • Triage Stage changed from Unreviewed to Ready for checkin

comment:3 Changed 8 years ago by mtredinnick

  • Patch needs improvement set
  • Triage Stage changed from Ready for checkin to Accepted

This is only half a solution (a lot of cases are still going to slip through) and trying to poke around in the exception string is a bit fragile. I'd rather that we tried to report a better traceback for the problem to guide the user to the correct location.

Leaving open for now, since it captures the problem, but I'd personally prefer to see an alternate solution for this one (it's a real problem; that's a given. Let's come up with a real solution).

comment:4 Changed 8 years ago by Bastian Kleineidam <calvin@…>

Can you tell what cases are still going to slip through?
And is there a way you can distinguish different ImportErrors without looking at the exception string? Perhaps that is what you meant by "real solution".

comment:5 Changed 8 years ago by guettli

  • Cc hv@… added

comment:6 Changed 8 years ago by gwilson

marked #9901 as duplicate.

comment:7 Changed 7 years ago by thejaswi_puthraya

  • Component changed from Uncategorized to Core framework

comment:8 Changed 5 years ago by julien

  • Resolution set to duplicate
  • Severity set to Normal
  • Status changed from new to closed
  • Type set to Uncategorized

I think this is essentially the same thing as #5904.

Last edited 15 months ago by timgraham (previous) (diff)

comment:9 Changed 5 years ago by Bastian Kleineidam <calvin@…>

  • Resolution duplicate deleted
  • Status changed from closed to reopened

This is not a duplicate of itself, is it?

comment:10 Changed 5 years ago by SmileyChris

  • Type changed from Uncategorized to Bug

comment:11 Changed 5 years ago by claudep

  • Easy pickings unset
  • UI/UX unset

The resolver code has evolved a lot during time, and seems now more selective about what is swallowed as a ViewDoesNotExist exception. Do you still think it's an issue? If yes, some more actual example would be welcome.

comment:12 Changed 4 years ago by claudep

  • Resolution set to needsinfo
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.
Back to Top