>>>>> "Guido" == Guido van Rossum <Guido.van.Rossum@cwi.nl> writes:
> In article <9502041329.AA23329=guido@voorn.cwi.nl>
> Guido.van.Rossum@cwi.nl writes:
...Stuff deleted...
>> We then get the following semantics:
>> enter object:
>> suite
>> 1. Call object.__enter__(). If this raises an exception, execution of
>> the enter statement is abandoned.
>> 2. Execute the suite.
>> 3. If suite terminates without raising an exception (not counting
>> exceptions handled within it), call object.__leave__(None, None, None).
>> 4. If the suite terminates with an exception, call
>> object.__leave__(exc_type, exc_value, exc_traceback).
>> 5. In either case, if the call to object.__leave__(...) terminates
>> normally, the enter statement terminates normally; if it raises an
>> exception, it may be handled in the scope containing the enter
>> statement. (There should be a way to emulate the effect of "finally",
>> which is not to disturb the stack trace. This is a separate, and
>> minor issue.)
> Cool.
>> It is possible that there are race conditions in this proposal that
>> worry the transaction processing experts (which I'm not).
> I don't see one.
Drats, I spoke too quickly. I see a problem with 1. Consider the
following __enter__:
def __enter__(self):
try:
self.begin()
except:
self.abort()
Suppose an interrupt causes an exception to be raised just after
executing the try statement. __leave__ will not be called and the
transaction created in the above try statement will not be aborted.
I think that __enter__ and suite need to be treated as a unit and that
__leave__ should be called even if an exception is raised in
__enter__. Is it possible for an exception to be raised *between* the
call to __enter__ and the execution of suite?
--
-- Jim Fulton jfulton@mailqvarsa.er.usgs.gov (703) 648-5622
U.S. Geological Survey, Reston VA 22092
This message is being posted to obtain or provide technical information
relating to my duties at the U.S. Geological Survey.