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

Reply via email to