Ok, thanks for your reply, I'll try to submit a patch with an original exception stored as soon as I figure out how to do that.
On Dec 2, 10:30 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---