I'm not sure I understand what you are trying to do, but *IF* I do,
then it is something I faced in dealing with recovery from loading
persistent objects (among other things). The strategy I took was to
slightly enhance what Guido suggested, and write code that looks like:
object.__lock__()
try:
succeeded = 0
suite
succeeded = 1
finally:
if succeeded:
commit
else:
rollback
object.unlock()
Is this what you are after?
> However, the transaction state is different. We need to "begin" on
> entering, but then there are TWO ways to exit the state: commit and
> rollback. We need to commit on success and rollback on failure (eg on
> an exception). try...finally... and locking... don't provide any way for
> the "leave" code to know which is the case. So, we need something that
> can support that.
I *think* the above construct clearly supports the two distinct exit
states. Is there something else I'm missing?
There are a number of situations I've found where I don't want to
disturb the traceback stack (and hence don't want to use an "except"
clause, which currently clears the stack etc), and I do want to detect
exceptions (as they fly by). The construct I've described above seems
to handle the problem nicely.
As Guido noted, try/finally is a pretty powerful and *significant*
variant in the exception handling process.
Jim
-- Jim Roskind InfoSeek Corporation voice: 408.982.4469 fax: 408.986.1889 jar@infoseek.com ---------------------------------------------------------------------------- PGP 2.6.1 Key fingerprint = 0E 2A B2 35 01 9B 5C 58 2D 52 05 9A 3D 9B 84 DB To get my PGP 2.6 Public Key, "finger -l jar@infoseek.com | pgp -kaf"