Negative

[Andrew Fedoniouk]

"Walter Bright" <newshound at digitalmars.com> wrote in message 
news:du2925$2cvj$1 at digitaldaemon.com...
>
> "Sean Kelly" <sean at f4.ca> wrote in message 
> news:du25eb$288m$3 at digitaldaemon.com...
>> Not in the above example, but then the above example doesn't even 
>> compile. I assumed you were talking about something like this:
>>
>> Foo f;
>> Bar b;
>> try {
>>     f = dofoo();
>>     b = dobar();
>> } catch( Object o ) {
>>     delete f; delete b;
>> }
>>
>> It's quite possible for f and b to both be uninitialized, yet I would 
>> expect the delete calls to be well-defined anyway.
>
> delete is well defined, and works properly with null. For more complex 
> unwinding, you'll need to add state variables to keep track of what has 
> been set and what hasn't.
>
> The new bug in the above code is that the catch block fails to rethrow o.

Let's say it was an intention. Pretty common by the way.

>
> I hope that these buggy examples show just how hard it is to get 
> try-catch-finally to be correct, and how easy it is to get the on_scope 
> correct. This leads me to believe that try-catch-finally is just 
> conceptually wrong, as it does not match up with how we think despite 
> being in common use for over a decade.

Well try first to explain what will happen on
on_scope_success { delete baz; throw foo; }
on_scope_exit { delete baz; throw foo; }

What "lexical order" will be used here? What scope guards will be invoked 
and so on.
Having on_scope_*** spread all other the "... lots of code ..."  will create
code maintainance nightmare as to trace visually what will happen and when 
will not
be a task for human anymore.

And as far as I understand main idea of on_scope_exit is a sort of poor man 
struct destructor...
I suspect that you are thinking about how to remove 'auto'/RAII, right?

Andrew.
http://terrainformatica.com