Don't hide errors when resolving URL views

[Bastian Kleineidam <calvin@…>]

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.

[Malcolm Tredinnick]

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).

[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".

[Gary Wilson]

marked #9901 as duplicate.

[Julien Phalip]

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

[Bastian Kleineidam <calvin@…>]

This is not a duplicate of itself, is it?

[Claude Paroz]

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.