On Sun, 2007-12-02 at 12:17 -0800, mezhaka wrote: > I have an assertion statement in my urls.py. When it throws an > AssertionError I do not get it. Instead I get the ImproperlyConfigured > error like this: http://dpaste.com/26524/. I had to dig into the > django code to understand what's happening. I have checked the svn for > previous version of urlresolvers.py : > $ svn diff -r 6584:5681 urlresolvers.py > > and it outputs the following: > --- urlresolvers.py (revision 5681) > +++ urlresolvers.py (revision 6584) > @@ -249,8 +249,9 @@ > except AttributeError: > try: > self._urlconf_module = __import__(self.urlconf_name, > {}, {}, ['']) > - except ValueError, e: > - # Invalid urlconf_name, such as "foo.bar." (note > trailing period) > + except Exception, e: > + # Either an invalid urlconf_name, such as "foo.bar.", > or some > + # kind of problem during the actual import. > raise ImproperlyConfigured, "Error while importing > URLconf %r: %s" % (self.urlconf_name, e) > return self._urlconf_module > urlconf_module = property(_get_urlconf_module) > > As from my point of view this is not correct -- the assertion is > decorated and it is hard to get what's going on. I've svn updated to > the previous version and now page behaves itself as I expect -- throws > AssertionError with a line number in urls.py. Shouldn't the new > version use VaueError as the previous version instead of the generic > Exception? Should I file a change request, bug or send patch? What > should I do to influence this behavior?
Let's slow down a bit here. There's no fundamental problem with converting exceptions from one type to another. It's a not a bug per se that we're changing the exception to something generically descriptive, even if it doesn't quite meet your requirements. We are making the error handling more robust for a reason: there are lots of exceptions that can be raised that were hard for people to catch and not really clear why they were occurring. At the time, I committed that, I did wonder about capturing information from the original exception. That's not unreasonable. Feel free to create a patch that stores, say, the original exception type, it's message and even the full traceback. But we do still want to raise a single identifiable exception from that point, so we can't change it back to just raising arbitrary stuff: it's too fragile for downstream code. I realise where you're coming from here, but both alternatives involve trade-offs and the current approach seems slightly better to me when I think about it. Regards, Malcolm > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---