-----Original Message-----
From: Barrie Slaymaker [mailto:[EMAIL PROTECTED]]
>[EMAIL PROTECTED] wrote:
>> 
>> It basically allows the programmer to "try" a certain action and see what
the
>> effects are going to be (i.e. handle the exception) so that some action
can
>> then be taken based on the results of the exception.

>Seems like any BLOCK could be an implicit eval {...} or try {...}, with the
>exception handling stuff triggered by following catch or (finally|cleanup)
>blocks:
>
>   {
>      kaboom ;
>   }
>   catch blah {
>   }
>   cleanup {
>   }
>
>This is like BLOCKs-as-loops.  Personally the extra 3 or 4 letters to spell
>eval or try don't matter that much to me, and it would make some folks feel
>more at home.  Though they could be optional, like 'return' before the
final
>expression in a sub.


I like this.  Mmmmm so sweet. 

Let me see If I have it...

try {...} is synonmous with eval {...} which is syntatic sugar for { ... }
any / all of which can:

        contain C<throw> statments

        be followed by (one or more?) catch blocks to evaluate code only if
somthing got tossed by the block

        be followed by one (or more??) finally blocks containing code to be
evaluated 
        requardless of the result of the  qw(try eval anon) block

So the changes, as far as diction is concerned would be:
        
        New keywords:
                try    (same as eval)

                catch  (same as C<else>, or maybe C<elsif>)

                finaly (same as {...})

                throw  (kinda like C<die>)

The catch being that throw does some stack preservation specialness, and
probably pushes some info onto an exception stack for later unwrapping when
main goes and tries to explain what happened.

So what am I missing (please not everyone at once ;)

-Corwin

Reply via email to