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? 


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to