I second what ajbeamon wrote. Any user exception will not be catched and raise as usual. See
Line 280, the
except FDBError will only catch FoundationDB errors.
tr.on_error(...) might raise a FDB error in case the transaction was retried too many times or that is a non-retryable error (e.g. transaction too large ?), and which case the
while not commited will stop. Just reading the Python code it seems that the transaction might retry indefinitly, but it is never the case.
By the way, given the fact that a transaction can be retried, you must make sure that the decorated function is idempotent e.g. you can’t send an email inside the transaction function and expect that it will only be sent only-once.
(On a somewhat related note, I am wondering whether the retry logic, should not be the responsability of the bindings instead of the C driver, in some cases you do not want to retry too much time if the transaction happens during an end-user HTTP request-response. One way to workaround it would be to have an “effort” or “timeout” in milliseconds provided by the user, and fallback to another approach in case the transaction can not succeed because of competition. Now that I wrote that, I figured it can be implemented in custom bindings or alternative