I think the transaction in which the error code operates in should be aborted.
Well, what if you want to make a note in some object (say the error_log), that something bad happened?
What if you want to make a change in the error handler?
My view is that the error handler should oeprate in it's own transaction, and be aborted if any exceptions are raised in it...
There is no other sane thing to do. I think this might be as easy as adding a few strategic get_transaction().abort() calls to various cases in Zope/App/startup.py's zpublisher_exception_hook. I don't have the time to untangle that mess at the moment, but I will enter a collector issue in.
...that said, I guess if you _really_ wanted to make changes in your error handler, would anything bad happen if your proposed changes are made, but the user's error handling code does a manaual get_transaction().commit() itself?
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce