Opened 15 years ago

Closed 10 years ago

Last modified 7 years 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: dev
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@…> 15 years ago.

Download all attachments as: .zip

Change History (13)

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

Attachment: no_exception_hiding.diff added

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

Has patch: set

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

Triage Stage: UnreviewedReady for checkin

comment:3 Changed 15 years ago by Malcolm Tredinnick

Patch needs improvement: set
Triage Stage: Ready for checkinAccepted

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 15 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 14 years ago by Thomas Güttler

Cc: hv@… added

comment:6 Changed 14 years ago by Gary Wilson

marked #9901 as duplicate.

comment:7 Changed 13 years ago by Thejaswi Puthraya

Component: UncategorizedCore framework

comment:8 Changed 11 years ago by Julien Phalip

Resolution: duplicate
Severity: Normal
Status: newclosed
Type: Uncategorized

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

Last edited 7 years ago by Tim Graham (previous) (diff)

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

Resolution: duplicate
Status: closedreopened

This is not a duplicate of itself, is it?

comment:10 Changed 11 years ago by Chris Beaven

Type: UncategorizedBug

comment:11 Changed 11 years ago by Claude Paroz

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 10 years ago by Claude Paroz

Resolution: needsinfo
Status: reopenedclosed
Note: See TracTickets for help on using tickets.
Back to Top