Toby Dickenson wrote:
On Monday 10 February 2003 8:47 pm, Shane Hathaway wrote:

Great, so there's at least 133 things to examine to see if they
could catch a ConflictError.  And I only wrote about 15 of those.
The rest could be very time-consuming to audit.
"tal:on-error" also catches all exceptions. It could be made to catch
all exceptions except ConflictError, but I don't feel like that's the
right solution.

A while ago I tracked down a bug in one of our products to a case where a mutator method failed half way. It raised an exception and left the object in an invalid state. This would be safe except for a dtml-try that swallowed the exception.
Recently I have been experimenting with this attached module to ensure that an application-level object can veto a transaction. I guess it would be applicable to ConflicctErrors too.
Ah-ha, that's a very elegant approach. By reusing the notional "transaction participant" interface, you didn't have to change the behavior of transactions in any way. Cool. We should definitely do it that way.

I'm thinking the veto should be added by Connection.commit() and Connection.setstate() whenever a conflict is about to propagate. What do you think?


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

Reply via email to