Opened 18 years ago

Closed 18 years ago

#4007 closed (wontfix)

404 and 500 handlers lack exception parameter

Reported by: mikko@… 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 Simon G. <dev@…>, 18 years ago

Triage Stage: UnreviewedDesign decision needed

comment:2 by anonymous, 18 years ago

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.

comment:3 by Malcolm Tredinnick, 18 years ago

Resolution: wontfix
Status: newclosed

You should be able to extract this inform with sys.exc_info(), so I don't think any changes are needed here.

Note: See TracTickets for help on using tickets.
Back to Top