On Thu, 2004-03-11 at 06:52, Chris Withers wrote:

> Well, what if you want to make a note in some object (say the error_log), that 
> something bad happened?

The error_log doesn't use persistent objects to keep its messages.

> What if you want to make a change in the error handler?

If anyone had been depending on this behavior in their current error
handlers, they would have seen weirdnesses in their applications like
those being reported now.  And no one has really complained, AFAICT. 
That leads me to believe it's a case of YAGNI (or even YNNI -- you never
needed it).

> My view is that the error handler should oeprate in it's own transaction, and be 
> aborted if any exceptions are raised in it...

I guess this is a reasonable strategy too, but I just wonder if it's
worth the bother.  I guess you might want to write to a transactional
relational database in your error page, but as far as I can tell no one
does this, because if they did they would probably be complaining about
lost records every so often.  Unless they just never noticed.

> ...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?

Not that I can tell.

- C

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

Reply via email to