Code review comment for lp:~spiv/bzr/cleanup-hof

> Vincent Ladeuil wrote:
> [...]
> > try:
> > no_error = False
> > try_func()
> > no_error = True
> > finally:
> > final_func(no_error)
>
> Ugh! And of course then you need to change final_func to reliably never
> raise errors depending on that flag... and then there are cases with multiple
> cleanups...

Not to mention the possibility of UnboundLocalErrors - unlikely in this simple case, but still possible if you just happen to get interrupted at the right time.

But Vincent's suggestion does point out something interesting, which is that the "has an error occurred" or "have things finished correctly" is often already available in the program state without needing a specific variable to be added for it. In the case we're primarily looking at here: if unlock runs and the medium(?connection?) is still in use, then we can be pretty sure that we were in fact interrupted. Now what should it do?

We can decompose this into:
How do we detect when we're in a knock-on error case?
What do we do differently?

The assumption is that we want to suppress errors only when they would be knock-on errors. I think we do want to squelch them in that case, but perhaps for some of these errors, like failure to unlock, they don't need to be propagated as errors at any time (outside of testing etc).