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