On Wed, Nov 18, 2009 at 8:28 PM, Alessandro Ronchi < alessandro.ron...@soasi.com> wrote:
> I get the same problem also with an Assert False (a typical debug symbol > I've used with mod_python). > > http://dpaste.com/122226/ > > no browser and no email, only logs. > > You seem to have put the assert False in settings.py, and the code is (still) dying during load of middleware, since that is triggering a load of settings. Look at the top of the trace. The code is here: http://code.djangoproject.com/browser/django/tags/releases/1.1.1/django/core/handlers/wsgi.py#L230 That is, within the call to self.load_middleware(). The special handling of exceptions that produces pretty debug pages and sends error email isn't done until you get into get_response (called down several lines from the load_middleware()): http://code.djangoproject.com/browser/django/tags/releases/1.1.1/django/core/handlers/base.py#L66 Specifically when that method call handle_uncaught_exception: http://code.djangoproject.com/browser/django/tags/releases/1.1.1/django/core/handlers/base.py#L136 which either produces the pretty error page or sends email, depending on DEBUG setting. Really, you can get both pretty debug pages and emails with mod_wsgi as well as you can with the development server or mod_python. I've seen both. The problem with both exception traces you have shown is that the exception is occurring too early in the processing -- neither of these exceptions you have posted would ever result in a debug page or an error email, regardless of deployment setup. Karen -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=.
