Hi All,

Chris McDonough wrote:
Is this the number of log messages that indicate a conflict error occurred (e.g. "x conflict errors since DATE" messages in the event log) or the number of conflict errors that are retried more than three times and thus make it "out" to the app user? I'm guessing the former.

I'm interested to see that this causes everyone the same level of confusion ;-) I'll reply to the other message about this though...

The real reason they're called "errors" is only because they're implemented as Python exceptions. They are implemented as exceptions because it was the easiest mechanism to use (exceptions are already built into Python).

Interestingly, you can raise things that don't subclass Exception in python. This was discussed before, and I firmly agree with, that zodb conflicts should _not_ sublcass exception. That way, there's less chance of them being caught by inexperienced programmers putting in try: except Exception: 's.

How would we go about making this change?

The Zope conflict exception catching code is written in such a complicated way (and without the benefit of any automated tests) that tracking that down could take an entire day which I don't have to burn ATM. So I'm afraid the status quo will prevail until someone gets so indignant about it that they either pay for it to be fixed or fix it themselves. Apologies for that. :-(

Okay, I'll bite, I might well be able to stump up the paid time on this if you guys can help me justify it as a performance improvement :-)

I hope I can count on a bit of moral and intellectual support if I manage to make this happen!



Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk

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

Reply via email to