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

If it is impossible, these use cases can be handled differently, of course...


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to