Opened 16 years ago

Closed 11 years ago

Last modified 9 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

Description

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@…> 16 years ago.

Download all attachments as: .zip

Change History (13)

by Bastian Kleineidam <calvin@…>, 16 years ago

Attachment: no_exception_hiding.diff added

comment:1 by Bastian Kleineidam <calvin@…>, 16 years ago

Has patch: set

comment:2 by Simon Greenhill <dev@…>, 16 years ago

Triage Stage: UnreviewedReady for checkin

comment:3 by Malcolm Tredinnick, 16 years ago

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 by Bastian Kleineidam <calvin@…>, 16 years ago

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

Cc: hv@… added

comment:6 by Gary Wilson, 15 years ago

marked #9901 as duplicate.

comment:7 by Thejaswi Puthraya, 15 years ago

Component: UncategorizedCore framework

comment:8 by Julien Phalip, 13 years ago

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

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

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

comment:9 by Bastian Kleineidam <calvin@…>, 13 years ago

Resolution: duplicate
Status: closedreopened

This is not a duplicate of itself, is it?

comment:10 by Chris Beaven, 13 years ago

Type: UncategorizedBug

comment:11 by Claude Paroz, 12 years ago

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

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