Re: Logging configuration and handle_uncaught_exception

In case anyone's interested in this but isn't following the ticket, I've attached an updated patch there using a variant of Vinay's suggestion, and with some shim code to address backwards-compatibility concerns. Reviews welcome. Ticket is at https://code.djangoproject.com/ticket/16288 Carl --

Re: Logging configuration and handle_uncaught_exception

On Jun 17, 1:48 pm, Matt Bennett wrote: > > This is a case for a custom Filter object [1]. The filter object > > implementation would only be a few lines, to reject logging when DEBUG > > is True, and can be attached to the admin email handler in the default > > logging

Re: Logging configuration and handle_uncaught_exception

On Fri, Jun 17, 2011 at 6:45 PM, Vinay Sajip wrote: > Matt Bennett writes: > >> >> > This is a case for a custom Filter object [1]. The filter object >> > implementation would only be a few lines, to reject logging when DEBUG >> > is True, and can be attached

Re: Logging configuration and handle_uncaught_exception

Matt Bennett writes: > > > This is a case for a custom Filter object [1]. The filter object > > implementation would only be a few lines, to reject logging when DEBUG > > is True, and can be attached to the admin email handler in the default > > logging configuration. [2] This way the

Re: Logging configuration and handle_uncaught_exception

Hi Julien, On 06/17/2011 12:08 PM, Julien Phalip wrote: > Just noting that another "filtering" functionality has recently been > added to trunk [1]. It is a different kind of filtering than what's > being discussed here -- it is to filter out sensitive information from > error reports when

Re: Logging configuration and handle_uncaught_exception

On Jun 17, 10:48 pm, Matt Bennett wrote: > > This is a case for a custom Filter object [1]. The filter object > > implementation would only be a few lines, to reject logging when DEBUG > > is True, and can be attached to the admin email handler in the default > > logging

Re: Logging configuration and handle_uncaught_exception

Hi Matt, On 06/17/2011 07:48 AM, Matt Bennett wrote: > Since logging Filters are not specific to an individual logger or > handler, I've just called it DebugFalseFilter. It's not a pretty name, > but I couldn't come up with anything better - I decided it should > convey what the filter allows

Re: Logging configuration and handle_uncaught_exception

> This is a case for a custom Filter object [1]. The filter object > implementation would only be a few lines, to reject logging when DEBUG > is True, and can be attached to the admin email handler in the default > logging configuration. [2] This way the logging call can occur in all > code paths,

Re: Logging configuration and handle_uncaught_exception

On 06/16/2011 08:47 AM, Russell Keith-Magee wrote: > The behavior that is implemented in the 500 handler is a bit > convoluted, but it was designed to be a drop-in replacement for the > behavior that existed in 1.2 -- i.e., server error emails were not > sent in DEBUG mode. I remember looking at

Re: Logging configuration and handle_uncaught_exception

On Tue, Jun 14, 2011 at 7:33 PM, Matt Bennett wrote: > On Mon, Jun 13, 2011 at 9:53 PM, Vinay Sajip wrote: >> On Jun 10, 2:05 pm, Matt Bennett wrote: >> >>> Is there a reason the call to logger.error can't come before we return >>>

Re: Logging configuration and handle_uncaught_exception

On Mon, Jun 13, 2011 at 9:53 PM, Vinay Sajip wrote: > On Jun 10, 2:05 pm, Matt Bennett wrote: > >> Is there a reason the call to logger.error can't come before we return >> the technical_500_response when DEBUG=True? It seems to me that the >> debug

Re: Logging configuration and handle_uncaught_exception

On Jun 10, 2:05 pm, Matt Bennett wrote: > Is there a reason the call to logger.error can't come before we return > the technical_500_response when DEBUG=True? It seems to me that the > debug level should be checked in each individual handler, rather than > determining whether

Logging configuration and handle_uncaught_exception

For the background to this problem please see my Stack Overflow question here [1]. I recently had to do some head-scratching over Django 1.3's logging configuration, because with DEBUG=True the 'django.request' logger isn't called when an uncaught exception occurs during a request. It wasn't