[RFC/MERGE][#243391] _run_and_cleanup helper (alternative to try/finally)

[Andrew Bennetts]

Martin Pool wrote:
> On Thu, Oct 9, 2008 at 12:13 AM, John Arbash Meinel
> <john at arbash-meinel.com> wrote:
> > Another thing to consider, why are our cleanup functions raising
> > exceptions? I believe in C++ if you raise an exception while an
> > exception is being propagated, you get a segfault. And I believe ~Foo()
> > is defined as unable to raise an exception.
> >
> > Perhaps we should consider pushing harder on preventing a second
> > exception. As reliably handling the various ways that you can get
> > multiple exceptions seems difficult at best.
> 
> That seems like an interesting approach.  You could actively avoid
> situations that might cause errors, like not trying to unlock if the
> transport is dead: things like this seems to account for most of the
> situations people actually hit.  Or, you could say that the contract
> for unlock and similar methods is that they don't raise exceptions.
> (Excluding SystemExceptions.)  They could log or record the error
> elsewhere.
> 
> This would possibly hide real errors if the command proper succeeds
> but unlocking fails.

I don't think we can hope that genuinely important exceptions can't
occur during unlock.  e.g. what about connection lost *during* an
unlock?

-Andrew.