I noticed that Zope 2.7 and Zope 2.8 changed the default zLOG implementation to use the logging package. There's one subtle consequence of that change that I wonder if people are aware of.
The zLOG.LOG() call takes an optional error argument that contains a 3-tuple of exception information as returned by sys.exc_info(). In the old zLOG, this exception was formatted and logged. In the new zLOG, the error argument is treated as a flag; if it is not None, the *current* exception is formatted and logged. Should I change my code to pass True for error instead of sys.exc_info()? There is at least one place in ZODB that is broken as a result of that change. The old API allowed code to capture an exception with sys.exc_info() and log it later. The common pattern seemed to be to capture the error, try to recover, and only log the original exception of recovery failed. I don't think there's a good solution to the problem, except to change all the code that tries to be clever about capturing exceptions. This affects some ZODB code that was a culprit in recent bug reports that locked up Zope. As a result my fix -- which was supposed to log a helpful traceback rather than prevent Zope from locking up -- probably didn't work. Should we give up on fixing this bug for Zope 2.7? Jeremy _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )