Re: AssertionError should not be wrapped in ImproperlyConfigured
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
-~--~~~~--~~--~--~---
Re: AssertionError should not be wrapped in ImproperlyConfigured
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
-~--~~~~--~~--~--~---
AssertionError should not be wrapped in ImproperlyConfigured
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?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
