#21777: Make request exception handling more robust to subsequent exceptions
-------------------------------+--------------------------------------
Reporter: patrakov@… | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Other) | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Comment (by patrakov@…):
OK, here is the simplest possible example code.
bug21777/urls.py:
{{{
from django.conf.urls import patterns, include, url
urlpatterns = patterns('',
url(r'^$', 'bug21777.views.buggyview'),
)
}}}
Relevant part of bug21777/settings.py, enough to reproduce the bug:
{{{
SECRET_KEY = 'dummy'
DEBUG = False
TEMPLATE_DEBUG = False
ALLOWED_HOSTS = ['*']
ADMINS = (('admin', '[email protected]'),)
EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
INSTALLED_APPS = (
'bug21777',
)
MIDDLEWARE_CLASSES = (
)
ROOT_URLCONF = 'bug21777.urls'
WSGI_APPLICATION = 'bug21777.wsgi.application'
}}}
bug21777/views.py:
{{{
from django.core.signals import got_request_exception
def buggyview(request):
raise ValueError("Let's pretend this is a bug in my application")
def handler(signal, sender, **kwargs):
# The handler is buggy, too
raise KeyError("Let's pretend that the handler itself is confused by
the original exception")
got_request_exception.connect(handler)
}}}
Test with ./manage.py runserver
Note: here it is important to understand the assumptions not expressed in
the code above. In my case, the handler was in some sense confused by the
original exception, not just "buggy by itself". So the original exception
in the view represents the primary problem, and the exception in the
handler is just a nasty consequence.
If you modify the handler so that it is non-buggy, and load the site root
URL, then you'll notice that Django sends the admin a nice e-mail with a
traceback pointing to the actual buggy view function, and with ValueError.
This is good. I have not put it into the above example, but in production
we also log all such errors to Apache logs, using logging.StreamHandler.
With the buggy handler, as written above, the e-mail is not sent, no debug
output mentions the original ValueError anywhere, and the KeyError related
to the confused handler gets logged to stderr. This makes it very hard to
debug the original problem in the view. In my opinion, the ideal situation
would be if both exceptions were properly logged. Especially since the
comment mentions the possibility of "another exception" and expresses the
intention to avoid overwriting the original exception info.
--
Ticket URL: <https://code.djangoproject.com/ticket/21777#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/076.8525d5dcdb7e4d01ae4d8ffeb5b532a2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
