Negative

[Regan Heath]

On Mon, 27 Feb 2006 19:54:23 -0800, Andrew Fedoniouk  
<news at terrainformatica.com> wrote:
> Seems like I realy don't understand something here...
>
> Why you think that your example is aesthetically
> better (technically they are the same) than this?

Wait, your example below is not technically the same as mine because:

1. My example (actually taken from the docs on digitalmars.com) used  
on_scope_failure, not on_scope_exit. on_scope_exit has the same effect as  
"finally" except...

2. The important feature of all of these statements is that they allow you  
to add items to the list of things to do _as you go_ and to then execute  
them in reverse lexical order at the appropriate time i.e. on_scope_exit  
or on_scope_failure etc.

The same cannot be achieved with catch or finally without nesting several  
of them. That is what the example I gave was designed to show I believe.

> Transaction abc()
> {
>     Foo f;   Bar b;  Def d;
>     try
>    {
>        f = dofoo();
>        b = dobar();
>        d = dodef();
>        return Transaction(f, b, d);
>    }
>    finally {
>       delete f; delete b; delete d;
>    }
> }

For the fun of it, lets re-write your example to use on_scope_exit:

Transaction abc()
{
    Foo f;   Bar b;  Def d;

    f = dofoo();
    on_scope_exit delete f;

    b = dobar();
    on_scope_exit delete b;

    d = dodef();
    on_scope_exit delete d;

    return Transaction(f, b, d);
}

I believe this is better that your try/finally example because:

  1- delete is not called on an unitialized class reference as in your  
example. (thankfully D initialises them to null)
  2- the init and delete of each object is in the same place (the larger  
the block of code this is used in, the better it gets).
  3- the resulting code is linear, which is easier to follow than some  
branching, indented, or nested try/catch/finally block.

Regan