try..catch..pass..finally Was: DMD 0.148 - scope guard

Tom Johnson Tom_member at pathlink.com
Tue Feb 28 06:48:26 PST 2006


Regan,

Your last post finally made me get it.

on_scope_* is a different kind of construct.  It's kind of like (imperfect
analogy coming) descending down a dynamic ladder.  If you have to go up again
on_scope_failure tells you which how to undo each "code rung" so you can go back
up.  The on_scope_success adds a last rung from the floor and on_scope_exit adds
codes at both ends of the ladder.  The analogy wears a bit thin because you can
do on_scope_exit failure and success multiple times.  

I have rtfa and all the previous messages and it still wasn't apparent that all
this was possible.

Thanks,

Tom


In article <ops5n86slk23k2f5 at nrage.netwin.co.nz>, Regan Heath says...
>
>On Tue, 28 Feb 2006 06:34:00 +0000 (UTC), Tom Johnson  
><Tom_member at pathlink.com> wrote:
>>> I'd say add another option to try..catch..finally paradigm.
>>>
>>> -S.
>>
>> Seconded.  For more fun, next we can debate whether the syntax should be:
>>
>> 1.  try..pass..catch..finally
>> 2.  try..catch..pass...finally
>> 3.  try..catch..finally..pass
>
>No, on_scope gives us more than try/catch/finally. Let me try this another  
>way.
>
>"catch" from try/catch/finally allows:
>  - you to execute a static/pre-defined set of code in the event that there  
>is a failure in the current scope.
>
>"finally" from try/catch/finally allows:
>  - you to execute a static/pre-defined set of code at the exit of the  
>current scope in all cases.
>
>Compare that to:
>
>on_scope_failure allows:
>  - you to add one or more sets of code, at the points at which they become  
>required, to the list of things to execute in the event of a failure.
>
>on_scope_exit allows:
>  - you to add one or more sets of code, at the points at which they become  
>required, to the list of things to execute at the exit of the scope in all  
>cases.
>
>To achieve the same thing that on_scope gives with try/finally requires  
>you to store state somewhere to indicate which parts of the finally block  
>to execute, or, it requires that you define several finally blocks and  
>nest them. Both of those options are no where near as neat as on_scope.
>
>I'm honestly baffled that people can't see the difference.
>
>Regan





More information about the Digitalmars-d mailing list