Opened 9 years ago

Closed 4 years ago

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

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

Download all attachments as: .zip

Change History (13)

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

Attachment: no_exception_hiding.diff added

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

Has patch: set

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

Triage Stage: UnreviewedReady for checkin

comment:3 Changed 9 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 9 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 Thomas Güttler

Cc: hv@… added

comment:6 Changed 8 years ago by Gary Wilson

marked #9901 as duplicate.

comment:7 Changed 8 years ago by Thejaswi Puthraya

Component: UncategorizedCore framework

comment:8 Changed 6 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 19 months ago by Tim Graham (previous) (diff)

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

Resolution: duplicate
Status: closedreopened

This is not a duplicate of itself, is it?

comment:10 Changed 6 years ago by Chris Beaven

Type: UncategorizedBug

comment:11 Changed 5 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 4 years ago by Claude Paroz

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