Code

Opened 7 years ago

Closed 7 years ago

#4007 closed (wontfix)

404 and 500 handlers lack exception parameter

Reported by: mikko@… Owned by: adrian
Component: Core (Other) Version: master
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: UI/UX:

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)
        

Attachments (0)

Change History (3)

comment:1 Changed 7 years ago by Simon G. <dev@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 7 years ago by anonymous

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 Changed 7 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.