On Thu, Jun 3, 2010 at 4:38 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > [...] > Regarding #13480 specifically -- I haven't dug into the problem in > detail, but the approach of telling exceptions apart by inspecting the > number of arguments doesn't fill me with joy. One of the changes in > 1.2 was to improve the ability to distinguish between import errors > caused by missing modules, and import errors caused by problems with > the module being imported; I'd like to think that we are now in a > better position to report the underlying cause of ImportErrors rather > than trying to wrap them.
Actually, the check against len(e.args) isn't intended to tell errors apart, just to avoid IndexError when we do check. The real test is the one just after (isinstance(e.args[1], ImportError)). Strictly speaking, len(e.args) could test for < 2, but using < 3 adds a little sanity checking for free. On the other hand, I freely admit that it's not the most elegant solution, hence my continuous grumblings to the effect of "It's a proof-of-concept; feel free to change it!" I put the patch together for two reasons: 1. To solve the immediate problem I had. 2. Because IRC wasn't certain that it was fixable without a major rewrite of Django. Elegance and the Right Way to do things don't factor in to either of those, so I hacked together a quick-and-dirty patch that sufficed. > Also - the patch appears to be against 1.0.2; does the patch still > apply to trunk? 1.2 saw a number of changes to the view handling and > the module loading code, so it wouldn't surprise me if the patch no > longer applies. Per the bug, "Code inspection suggests that the problem still exists in SVN, and the attached patch applies to SVN successfully, albeit with some grumbling about the line numbers being wrong." I also gather that axiak, who bumped the bug version to SVN, tested the patch to see how it worked, presumably against trunk. I have not personally tested it in action against trunk, but all signs point to it working. > [1] http://code.djangoproject.com/wiki/BetterErrorMessages The issues listed there all appear to be cases where error messages are given, but are insufficient or misleading. This issue is, to my mind, somewhat more severe, because no error message is shown to the developer at all. Django itself crashes, the webserver spits out an error, and the real error gets hidden in the server logs. > I'm not convinced there will be a strong overlap here. I'm sure > Arthur's code will probably overlap - after all, he is dealing with > model loading - but I don't see that what he is doing directly relates > to the errors that are raised during loading. I wouldn't be at all > surprised if his new importer just inherits whatever error handling > already exists. Makes sense. Still, it's a good idea for the two to be aware of each other, to avoid stepping on each other's toes more than necessary. -FM -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
