Negative

[Sean Kelly]

Don Clugston wrote:
> Walter Bright wrote:
>> 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. 
> 
> This is very interesting. Seems to me that these on_scope_xxx are kind 
> of "naked destructors". If you consider them to be the low-level 
> construct, then putting a destructor into a class means: when the 
> constructor is called, insert "on_scope_exit ~this()" at the same time.

on_scope does practically eliminate the need for an 'auto' keyword, 
assuming auto classes would be allocated on the heap either way.

> Is the convoluted nature of the RAII solution simply because
> the same destructor is executed regardless of whether the function was 
> exited normally, or whether an exception occurred? And because there's 
> no easy way of determining if you are inside an exception handler. So 
> you only have "finally", without "catch".
> I wonder if destructors could be jazzed up, so that they can insert an 
> "on_scope_failure" as well as "on_scope_exit"?

I've considered adding functionality to Ares to allow a user to 
determine if an exception is currently in flight--C++ offers this but 
it's little used as it's not terribly reliable.  But with on_scope there 
seems little need for this.

> Maybe called ~catch()?
> 
> class Foo
> {
> ~catch() {
> unwind_foo();
> }
> }
> 
> class Bar
> {
>   ~this() { // destroy bar
>    }
>   ~catch() {
>    unwind_bar();
>   //  now we go to ~this(), which behaves like finally.
>   }
> }
> 
> Transaction abc()
> {
>     Foo f;
>     Bar b;
>     Def d;
> 
>     f = dofoo();
>     b = dobar();
>     d = dodef();
> 
>     return Transaction(f, b, d);
> }
> 
> Doesn't have the flexibility of on_scope, where you have access to all 
> variables -- but on the other hand, it has the RAII benefit that users 
> of the class don't need to remember to do it.

True.  But I would argue that the burden of writing exception-safe code 
is on the function writer moreso than the class writer, largely because 
the class writer can't predict or address every way that his class may 
be used.  on_scope also allows a bit more flexibility:

{
     Foo f = acquireFoo();

     on_scope_exit    f.commitAll();
     on_scope_failure f.unwindAll();

     f.setFirst();
     {
         f.setSecond();

         on_scope_failure f.unwindLast();
     }
}


Sean