Christian Boos wrote: > Rather, the comparison with the "with" approach made me think we should > instead propagate the value returned by the implementation function, > otherwise we would have no way to communicate something from there to > the outside.
Not quite true. The usual trick is to allocate a list in the surrounding
scope, and to mutate the array in the transaction function.
retval = [0]
@with_transaction(env, db)
def renamne(db):
# ... transaction body ...
retval[0] = 1
> So maybe the best approach would be a flag passed to the decorator (or
> context manager) telling if the exception should be propagated, so we
> could have 1. by default and not have to write a try/except in this
> case, 2. by writing an exception handler inside the transaction body and
> 3. by setting that propagate flag to True.
I don't like that all too much, but maybe it's just because I don't have
a use case yet where we would like to catch the exception. I think I
would rather have an explicit try: except: block if I want to catch
exceptions, as opposed to its being "swallowed" magically by the
decorator or context manager. Remember, explicit is better than implicit :)
Could we start with as little magic as possible, and only add the magic
if/when we really need it?
-- Remy
signature.asc
Description: OpenPGP digital signature
