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!
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Dev maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
