On Tue, 2003-02-11 at 13:19, Shane Hathaway wrote: > 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?
Maybe I don't understand all the transaction code correctly, but shouldn't it be set in ConflictError.__init__()? I suggest that we also take the ConflictError.__init__() opportunity to store a representation of the current traceback. This representation would be dumped to zLOG in case the veto has to be enforced, so that we know when the ConflictError originally happened. This way we can take steps to remove the offending generic "except:". -- Ideas don't stay in some minds very long because they don't like solitary confinement. _______________________________________________ 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 )