Opened 19 years ago
Closed 19 years ago
#4007 closed (wontfix)
404 and 500 handlers lack exception parameter
| Reported by: | Owned by: | Adrian Holovaty | |
|---|---|---|---|
| Component: | Core (Other) | Version: | dev |
| Severity: | Keywords: | handler500 handler404 404 500 exception middleware process_exception | |
| Cc: | Triage Stage: | Design decision needed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
In Django 0.96, both django.conf.urls.defaults.handler404 and handler500 URL mappers don't take an exception parameter. This means that these handlers cannot be used to log exceptions on a production server.
I have a workaround for 500 handling which works for Django 0.96. We use process_exception middleware to handle exceptions. Unfortunately base handler doesn't raise 404 as exception when resolving failed, so we cannot override handler404 this way.
class ExceptionMiddleware:
""" Log all exceptions coming through.
Workaround Django 0.96 limitation of not giving exception parameter
to the 500 handler. You must have DEBUG = False in and
this middlware installed in settings.py before the handling
becomes effective.
You must *not* have django.conf.urls.defaults.handler500 defined.
"""
def process_exception(self, request, exception):
# Using Python logging API
logger = logging.getLogger("exception_logger")
logger.debug("ExceptionMiddleware triggered")
# 404 exceptions never reach here -
# django.core.handlers.base logic should be changed first
#
#if isinstance(exception, http.Http404):
# # Handle missing pages
# # Log exception and display 404 page
# logger.exception(exception)
# return do_404(request)
#else:
# Handle errors
# Log exception and display internal server error page
logger.exception(exception)
return do_500(request)
Change History (3)
comment:1 by , 19 years ago
| Triage Stage: | Unreviewed → Design decision needed |
|---|
comment:2 by , 19 years ago
comment:3 by , 19 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
You should be able to extract this inform with sys.exc_info(), so I don't think any changes are needed here.
I think it could be feasible to move the current debug/special cases out from the base handler to their own dedicated middleware (ExceptionDebugMiddleware or similar). This would clean up the base handler code a bit.