Negative

[Andrew Fedoniouk]

>
> Technically, they are not the same. The above version *always* deletes f, 
> b and d, but it's not supposed to if the function succeeds. Only if 
> dofoo(), dobar(), or dodef() throws are f, b and d supposed to be deleted.

Ok, mea culpa.

>
> This is the whole problem with try-finally. It works great with trivial 
> problems, and all the tutorials and example code unsurprisingly only show 
> trivial problems. Try scaling it up for things like multi-step 
> transactions, and it gets very complicated very fast, and it gets very 
> hard to get right.

Well, I spent year programming on PocketPC in eVC where are no such
things as exceptions. In principle. Not implemented in C++ compiler.
Still alive :)

>
> Here's the on_scope version:
>
> Transaction abc()
> {
>    Foo f = dofoo();
>        on_scope_failure delete f;
>    Bar b = dobar();
>        on_scope_failure delete b;
>    Def d = dodef();
>        on_scope_failure delete d;
>    return Transaction(f, b, d);
> }
>
> Scaling it up is as easy as linearly adding more on_scope statements, and 
> easy to get it right.

True.

But
Transaction abc()
{
    try {
      Foo f = dofoo();
      Bar b = dobar();
      Def d = dodef();
      return Transaction(f, b, d);
   } catch(object er) {
        delete f; delete b; delete d;
   }
}
is not worse to be honest.

I would think rather about extending mixins to allow to add
on_scope_exit as a custom template conrstructions.

Like mixins taking block {} as a parameter:

template on_scope_exit(B)  auto Auto t = new Auto(B);

... and in Galaxy far far away:

mixin on_scope_exit{ delete foo; }

So anyone can implement needed policy for himself.

I mean on_scope_exit is only one particular way of dealing
with the problem. There are and will be others.

Huh?

Andrew.