On Fri, Aug 8, 2014 at 4:38 PM, Chris Angelico <[email protected]> wrote:
> On Sat, Aug 9, 2014 at 8:01 AM, Chris Kaynor <[email protected]> > wrote: > > However, I'd recommend re-raising the exception after rolling back the > > transaction with a bare "raise" statement right after the db.rollback() > - at > > the absolute minimum, you should log the error. This will likely let you > see > > what your problem is. > > AIUI, aborting the process with an uncaught exception would roll back > implicitly, so there's no need to "bare except, roll back, bare > raise". But even if that's not the case, I would be looking at a > try/finally for this, rather than a try/except/raise. > I would imagine that on connection close, the server would rollback any uncommitted transactions, however that presumes that the connection close is completed in a reasonably timely manner (with a try...finally for closing, it should be). This is one case where I think try...except/raise is better than try...finally. If you use try...finally to rollback, you'd have to either track whether you committed, or you'd rollback with no actions (or possibly a committed action, which could have odd behavior, depending on the implementation) try: action commit except: rollback raise I feel is better than: try: action commit finally: rollback or: success = False try: action commit success = True finally: if success: rollback and is very different than: try: action finally: commit
-- https://mail.python.org/mailman/listinfo/python-list
