Toby Dickenson wrote at 2003-2-3 10:40 +0000:
On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote:
This is flawed as error handling is done outside of a transaction.
Excellent analysis. A futher problem is that this could cause dangling references, and a subsequent POSKeyError, since persistent objects can be
passed from one transaction to the next inside the exception and tracebac k.
The same applies to your prorosed fix. I see...
Difficult to handle when the error handling expects a true traceback object -- unless we postpone the transaction abort until error handling is complete. But then, error handling can not commit things.
Is there a need to allow the error handling transaction to commit? I propose it always be aborted. I think it can be useful:
* a colleague uses Jens' transactional mail host (throughout Zope) and he sends error mails out of "standard_error_message". When error handling actions would be aborted, he would need to use a non transactional mail host * in an earlier project, we put error records in "standard_error_message" into a relational database in order to use SQL for statistical evaluation. If it is impossible, these use cases can be handled differently, of course... Dieter