Negative

[Andrew Fedoniouk]

"Regan Heath" <regan at netwin.co.nz> wrote in message 
news:ops5nhbgii23k2f5 at nrage.netwin.co.nz...
> On Mon, 27 Feb 2006 10:42:10 -0800, Andrew Fedoniouk 
> <news at terrainformatica.com> wrote:
>> I am with Charles here...
>>
>> I don't understand why
>> on_scope_failure & co. are significantly better than
>> try catch finally?
>>
>> What is wrong with them?
>>
>> Semantically try-catch-finally are well known and
>> widely recognizable constructions.
>>
>> BTW: Am I right in my assumption that
>> proposed on_scope_exit / on_scope_success / on_scope_failure
>> is a direct equivalent of the following:
>>
>> try
>> {
>>    [scope code]
>>    my_on_scope_success().
>> }
>> catch(...)
>> {
>>    my_on_scope_failure().
>> }
>> finally {
>>   my_on_scope_exit().
>> }
>>
>> If yes then again what it wrong with them in principle?
>
> For a simple example it is very similar, for a more complex one it's not. 
> Have you read this:
>   http://www.digitalmars.com/d/exception-safe.html
>
> Here is my attempt at "explaination by example", a more complex example 
> and it's equivalent using try/catch/finally.
>
> Transaction abc()
> {
>     Foo f;
>     Bar b;
>     Def d;
>
>     f = dofoo();
>     on_scope_failure dofoo_unwind(f);
>
>     b = dobar();
>     on_scope_failure dobar_unwind(b);
>
>     d = dodef();
>
>     return Transaction(f, b, d);
> }
>
> as try/catch/finally:
>
> Transaction abc()
> {
> Foo f;
> Bar b;
> Def d;
>
> f = dofoo(); try {
> b = dobar();
> try {
> d = dodef();
> return Transaction(f, b, d);
> }
> catch(Object o) {
> dobar_unwind(b);
> throw o;
> }
> }
> catch(Object o) {
> dofoo_unwind(f);
> throw o;
> } }
>
> Note, the order of the unwind calls is important:
>   http://www.digitalmars.com/d/statement.html#scope
>   "If there are multiple OnScopeStatements in a scope, they are executed 
> in the reverse lexical order in which they appear."
>
> There are many benefits of on_scope over try/catch, they are:
>
> 1. less verbose, with less clutter it's easier to see the purpose of the 
> code. on scope scales well to handle many 'transactions' which require 
> cleanup, like the example above, try/catch/finally does not, it gets 
> horribly nested and confusing.
>
> 2. groups the cleanup code with code that requires it, less seperation 
> between the thing that is done, and the thing that cleans up after it. 
> try/catch/finally has the cleanup code in a seperate 'catch' or 'finally' 
> scope often a long way from the code that creates the need for that 
> cleanup.
>
> Regan

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?

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;
   }
}

I can easily accept on_scope_failure if
it would solve something in principle.
But so far it is a reformulation of VBs onerror/resume as
far as I can see.

Andrew Fedoniouk.
http://terrainformatica.com