Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Magentus <mag...@gm...>]

On Thu, 20 Nov 2008 10:39:26 -0800, 
Joe English <jen...@fl...> wrote:

>     handle {code ?resultVar ?optionsVar??} { script }

Is there any actual practical use to putting code in the braces?  The
variables, I don't think can be avoided in this style, although I'm not
sure that there is a need to have every single branch specify the
variables individually.  I'd much prefer to have them specified once at
the top (and optionally at that) rather than repeated monotonously on
every single branch.....

Something like a:
    withvars {resultVar ?optionsVar?}
following the main try script indicating where to stash the variables.
(I did mention that in my last post that hasn't yet been passed through)

Although personally I'd prefer a -vars option to [try], despite the
obvious issue of not being allowed to have a command called -vars that
_takes no arguments_.  Is anyone seriously going to try and insist
that that's a big issue?!?  If it's a variable name, then fine, it's a
very realistic problem, but what static script is going to non-obviously
conflict (the main use-case), and for passed in scripts through
variables, just use the -- guard option.  From using [switch], it's
common to put -- before variables anyhow.  I know a "Better Way" would
be preferably, but it's the least ugly and most practical so far.


In any case, a nice clean simple layout seems to be:
    handle pattern {...}
where the return code is TCL_ERROR and pattern is glob matched against
errorcode.
    on code pattern {...}
now pattern matches against the return value, even if code is
TCL_ERROR.  More usefully, it'll gracefully handle applications which
have multiple kinds of success, as well as multiple kinds of error,
and can handle both regular bare [error] returns and the use of
errorcode with equal ease.

Supporting all the different types of match, though, would be a "Good
Thing".  -glob, -nocase, -exact, -prefix, -regexp, and so forth...
That's why I think the next part is worth giving a second thought.


For the blending with [if] option, there was chatter a while back about
fast [expr]-local variables intended mostly to hold partial results
during an expression; the main terms of the options dict could quite
readily be pre-loaded as [expr]-local variables.

A little care might be needed to avoid shadowing the variable you wish
to use to hold the value to compare, but that should be doable.
Perhaps [expr]-local variables should use a %syntax synonymous with the
regular $syntax for variables to avoid name clashes (and highlight
the fact that they're [expr]-local).

All this could further be put off by implementing it as a separate
[try] term later, for when extended matching is needed. Then you've got
"handle" and "on" for just about everything, and "when" or even "if"
for anything else.  (Imagine an ambiguous case among more readily
matchable cases, that would otherwise force you to break the [try] into
a much less easy to read chunk of code.)


-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 44 days, 21:32)