Author vinay.sajip
Recipients daniel.passaro, vinay.sajip
Date 2016-12-26.18:37:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1482777455.28.0.573413537431.issue29056@psf.upfronthosting.co.za>
In-reply-to
Content
I don't consider this a bug, as the logging documentation for the Handler.format() method states:

"Note that the formatted exception information is cached in attribute exc_text. This is useful because the exception information can be pickled and sent across the wire, but you should be careful if you have more than one Formatter subclass which customizes the formatting of exception information. In this case, you will have to clear the cached value after a formatter has done its formatting, so that the next formatter to handle the event doesn’t use the cached value but recalculates it afresh."

So, your suggested workaround is following the approach suggested in the documentation.

We could change the implementation to allow a cache_exception_text attribute (defaulting to True, set in the Handler class), then it could be set to False for individual instances by application developers. This does introduce another attribute to the handler class, so this would have to be added in 3.7 and not in 3.6. I'm not sure it's worth making this change, because the use case for it is not that common.
History
Date User Action Args
2016-12-26 18:37:35vinay.sajipsetrecipients: + vinay.sajip, daniel.passaro
2016-12-26 18:37:35vinay.sajipsetmessageid: <1482777455.28.0.573413537431.issue29056@psf.upfronthosting.co.za>
2016-12-26 18:37:35vinay.sajiplinkissue29056 messages
2016-12-26 18:37:34vinay.sajipcreate