On Wed, Jun 2, 2010 at 1:58 AM, Charlie Nolan <funnyman3...@gmail.com> wrote: > It was suggested in bug #13480 that I raise this issue "during the 1.3 > feature discussion phase", which we seem to have entered. > > Essentially, the issue is that a typo in my_app/views.py or any of its > dependencies can raise an error on module import and break the entire > site, leaving the user with a completely uninformative > webserver-provided error page. This error page is /not/ the one > provided by Django when DEBUG is enabled in settings.py. Effectively, > DEBUG is locked off for this type of error. It's also possible that > the standard non-DEBUG error page mechanisms are bypassed as well, but > I have not tested this. > > Adding either of following two lines to the start of my_app/views.py > will trigger this behavior: > > import djagno # ImportError > print print "Hello, world!" # SyntaxError. > > Attached to bug #13480 you will find a proof-of-concept patch that > catches both of these errors and reroutes them to the standard (i.e. > DEBUG-respecting) error mechanisms. I call it a proof-of-concept > because I took the minimum steps necessary to solve the problem as I > experience it. Django as a whole might be better served by a more > comprehensive solution... or simply one written by someone who has > enough experience with Django's internals to see the Right Way to > handle things. You are, of course, welcome to use the patch as > written if you find it adequate.
There are many areas in Django's codebase where error reporting could be improved; see [1] for a working list of some of them. If someone wants to make a project out of addressing these issues, they certainly have my blessing. 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. 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. [1] http://code.djangoproject.com/wiki/BetterErrorMessages > As I mentioned to Arthur Koziel a few days ago, a cursory glance at > his GSoC summary suggests that there may be some overlap between that > and this change. I'm not sure whether that's important to this > proposal or not. 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. Yours, Russ Magee %-) -- 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.
