On Wed, Jun 15, 2011 at 1:31 PM, [email protected] <[email protected]> wrote: > Hi Russell, > > and what do you say about showing call stack properly? > > The problem is not ViewDoesNotExist itself, but throwing away useful > traceback. > > If we do instead: > import sys > try: > self._callback = get_callable(self._callback_str) > except ImportError, e: > mod_name, _ = get_mod_func(self._callback_str) > raise ViewDoesNotExist("Could not import %s. Error was: %s" % > (mod_name, str(e))), None, sys.exc_info()[2] > > This way we will not only see not only exception where was required > module that was not imported, but also how it was attempted to be > imported -- often there's cyclic imports, few other imports or > initializations causing other imports, which are hidden with simple > raise.
To my mind, this isn't the right approach -- it's papering over the problem, not fixing it. In this case, the underlying problem is that ImportError is actually catching 2 different errors: 1) The view specified doesn't exist 2) The module containing the view contains an error. The current implementation catches both errors, and turns them into a ViewDoesNotExist error. You don't fix this problem by providing better stack trace information on a ViewDoesNotExist error -- you fix the problem by actually separating the two errors, making (1) return ViewDoesNotExist, and (2) return ImportError. That way, you'll get a meaningful error message *and* reliable stack trace data. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
