I stand by what I said in the dev channel yesterday: this is one
instance of a more general issue (there are lots of places where --
because we need to import or check something -- we can end up
"swallowing" exceptions in this fashion), one which will require time
and thought to deal with, and which should not be tackled piecemeal.
Given that, and the fact that there's a lot of much more critical work
to do, I think the appropriate time to do that is **after** Django
1.0. This is simple prioritization (and, as others have pointed out to
you, the fact that there hasn't been a big flood of bug
reports/support problems related to this probably indicates it's not
as critical as you're making it out to be).
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
I stand by what I said in the dev channel yesterday: this is one
instance of a more general issue (there are lots of places where --
because we need to import or check something -- we can end up
"swallowing" exceptions in this fashion), one which will require time
and thought to deal with, and which should not be tackled piecemeal.
Given that, and the fact that there's a lot of much more critical work
to do, I think the appropriate time to do that is **after** Django
1.0. This is simple prioritization (and, as others have pointed out to
you, the fact that there hasn't been a big flood of bug
reports/support problems related to this probably indicates it's not
as critical as you're making it out to be).
Yes. I'd rather have thought put into A) whether it's worth doing
something (after all, this is really more of a Python thing -- Python
has "except", not "except but only when the exception was in the last
stack frame") and B) what that thing is. I don't want to end up with a
patchwork of different solution because different cases ended up with
different people passionately arguing about how best to solve them.
> This one, I think, is worth fixing sooner rather than later. I don't even
> know if the others are worth worrying about, since I can't say I recall any
> people on the users list running into trouble with other cases of this
> exception-swallowing behavior. This one I definitely have seen causing
> problems, triggered by newforms-admin causing a lot more code to get
> executed when urls.py is loaded.
Then we need a *general* solution, that can and must be applied to all
the various places where we do stuff like this (template tag loading
also has the potential to "swallow" exceptions, as do other areas of
URL resolution, as does middleware loading, as do... well, lots of
stuff in Django). But again I think this comes down to prioritization;
it's really less of a bug in Django than it is an attempt to help
people rescue their own broken code (since the root of the issue is
that somebody will have broken code somewhere and the "real" exception
is masked when something else incidentally bumps against it), and we
still have plenty of genuine bugs where things in Django don't work
properly. So I still think this is a post-1.0 thing.
Jacob
Sent from my iPhone
On Aug 24, 2008, at 1:31 AM, "James Bennett" <ubern...@gmail.com>
wrote:
>
Quick note: Malcolm and I are in Portland in the only place in the
city sans wifi. We've talked about this and the other exc swallowing
issue and I have some thoughts. Please hold until I'm in a more
civilized location and can actually use a keyboard bigger than a few
stamps.
Yeah, I'm sorry; I lost track of this.
Essentially I think that James is right that a systematic fix would be
better, but I don't see what that might look like.
Unfortunately, I'm really not sure exactly what we can do -- there's
some places where perhaps we could not raise ImproperlyConfigured, but
the problem is that sometimes those messages are *more* helpful, and
other times less. It's not entirely clear (to me) what a fix, even a
half-assed one, would look like
I started going down the path of having ImproperlyConfigured take an
``original_exception`` argument and displaying that original exception
from manage.py, but that's pretty fiddly.
So I think we need to do something along the lines of what's in
#7524... it's far, far from perfect, but it's probably the only way to
go to avoid a lot of frustration.
Jacob
So I think we need to do something along the lines of what's in
#7524... it's far, far from perfect, but it's probably the only way to
go to avoid a lot of frustration.
On Tue, Aug 26, 2008 at 3:38 PM, Karen Tracey <kmtr...@gmail.com> wrote:So it's a couple of days later...got time to update with your thoughts?Yeah, I'm sorry; I lost track of this. Essentially I think that James is right that a systematic fix would be better, but I don't see what that might look like. Unfortunately, I'm really not sure exactly what we can do -- there's some places where perhaps we could not raise ImproperlyConfigured, but the problem is that sometimes those messages are *more* helpful, and other times less. It's not entirely clear (to me) what a fix, even a half-assed one, would look like
> I started going down the path of having ImproperlyConfigured take an > ``original_exception`` argument and displaying that original exception > from manage.py, but that's pretty fiddly.
So I think we need to do something along the lines of what's in #7524... it's far, far from perfect, but it's probably the only way to go to avoid a lot of frustration.
-- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de