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
-~--~~~~--~~--~--~---
