Negative

[Sean Kelly]

Walter Bright wrote:
> "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.

That's all I was asking.  I wondered at the implications of:

"there's still a serious bug - if dofoo() throws an exception, then the 
catch statement will attempt to delete b and d, which are not even 
initialized yet"

> The new bug in the above code is that the catch block fails to rethrow o.

Arguably not a bug, as this could be intended behavior.  However, I 
would think it's clear that the above code was merely intended to 
clarify a previous statement.  I wouldn't suggest that it is correct or 
well-written :-)

> 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.

I've been sold on Andrei's method since he first introduced it, so no 
issue there.  It's certainly far simpler and more meaningful than the 
backflips often required by RAII.  And while the proposed C++ shared_ptr 
syntax makes some progress for this purpose, it's still a far cry from 
on_scope_*, particularly when paired with inner functions.


Sean