Re: Logging configuration and handle_uncaught_exception
On Fri, Jun 17, 2011 at 6:45 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> Matt Bennett <matt@...> 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 logging call can occur in all
>> > code paths, and the admin email handler itself can remain
>> > general-purpose, but the backwards-compatible behavior can be maintained.
>> >
>> > Matt, if you'd be willing to open a ticket for this, that'd be helpful.
>> > If you feel like putting together a patch using the Filter approach,
>> > that'd be even better
>>
>> Here you are: https://code.djangoproject.com/ticket/16288
>>
>> 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 through, but AFAIK there's no name for
>> "not debug mode".
>
> Reposting this, after Google swallowed my earlier response. Sorry if it
> eventually turns up, making this a double post ...
>
> A more general solution would be something like this:
>
> class ConditionFilter(logging.Filter):
> def __init__(self, condition):
> self.condition = condition
>
> def filter(self, record):
> return self.condition
>
> which you can then use in the logging configuration using something like
>
> 'require_debug_false': {
> '()': 'django.utils.log.ConditionFilter',
> 'condition': not DEBUG,
> }
>
> This will allow the filter to be used in more places, e.g. you could use a
> more
> complex settings-time condition.
>
> Regards,
>
> Vinay Sajip
>
+1. Perhaps the reason I don't like DebugFalseFilter as a name is that
it's so specific.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
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, and the admin email handler itself can remain > general-purpose, but the backwards-compatible behavior can be maintained. > > Matt, if you'd be willing to open a ticket for this, that'd be helpful. > If you feel like putting together a patch using the Filter approach, > that'd be even better ;-) Here you are: https://code.djangoproject.com/ticket/16288 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 through, but AFAIK there's no name for "not debug mode". Matt. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Logging configuration and handle_uncaught_exception
On Mon, Jun 13, 2011 at 9:53 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > On Jun 10, 2:05 pm, Matt Bennett <m...@bennett.name> 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 the error is passed to the logger at all. > > Aren't these two separate things? It makes sense to have the logging > of errors occur in all code paths, but that isn't connected with > levels on handlers. The first requires the logging call to be added to > the code, whereas levels on handlers can be configured to be as > verbose (or not) as you like, independently of logging calls in the > code. > I think we're saying the same thing - my point is that the logging of errors should occur in call code paths. Currently, an unhandled view error is *not* logged if settings.DEBUG is True. To be clear, this has nothing to do with the log levels on the handlers. I've attached a patch which modifies django.core.handlers.base.handle_uncaught_exception to log the error, and stops AdminEmailHandler sending email if settings.DEBUG is True. Hopefully this makes it clear what I was proposing above. Curiously, the modification to AdminEmailHandler causes several tests in regressiontests.views to fail. The tests that fail are trying to validate that the contents of emails sent conform to the various configured settings, and they expect email to be sent even if settings.DEBUG is True - which isn't what happens when django processes a real view. For my patch to pass, I could simply drop the modification to AdminEmailHandler, or update the tests so that email is not expected if settings.DEBUG is True (which arguably should be changed anyway). Matt. > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. debug-logging.diff Description: Binary data
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 obvious at all to me that 500 errors are only processed by the logger when not in debug mode. This behaviour made sense when the only error processing was to send an email to the site admins, but now we're free to add more handlers to the logger and may want some of them to be enabled in development as well as in production. 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 the error is passed to the logger at all. Regards, Matt. [1] http://stackoverflow.com/questions/6305132/django-1-3-logging-500-errors-are-not-logged -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
