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

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

On Sun, 23 Nov 2008 14:45:17 +0200, 
Twylite <tw...@cr...> wrote:

> (g) Discourage the use of the result for determining the nature of
> the error (an in doing so encourage the use of -errorCode).  At the
> very least this means not having default support for matching on the
> result.

Keeping in mind that the return result might be the NORMAL place to
match for SOME return codes.  Namely OK and custom codes >4.


> (b) Handlers are identified by keywords.  The keyword "catch" has
> been argued against (confusion with existing language
> feature/keyword), as has "except" (ambiguous - "with exception" or
> "except for").  Likely candidates are "on" and "handle".

I like "on" for the generic catch-a-return-code case, and "handle" as
in handle-the-error.


> (d) Taking (c) to its logical conclusion, [try] must be specified and 
> implemented to support user-selectable pattern matching.  It is
> possible to have the matcher selected for the [try] as a whole, or
> per handler, and there are pros and cons to each approach.

Definitely per-handler.  But source and test are different things;
message source will mostly be dependant on the return code, where any
of the basic types of string match test can be applied to every possible
message source.  So unless you want every combination of source and
test explicitly spelt out in its own matcher, they need to be separate.

If a whole new error passing paradigm evolves, a new [try] token can be
built to work with it, which could be as simple as a new term which
takes a sub-set of the existing terms as its first argument, and
emulates those terms (I doubt the existing code will be particularly
reusable in that case anyhow).


> (b) The behaviour of the [try] should be predictable and conform to
> the principle of least surprise.  On particular consequence of this
> is that matchers must consider handlers/errorPatterns in
> left-to-right order, and  all handlers should be executed in the same
> fashion (implying that the [try] rather than the matcher should
> execute the handler body).

Would it make sense to "accumulate" finally bodies as you go through,
until you reach an active handler.  This would mean there's a subtle
twist and a bit of surprise, in that the finally block should be right
behind the main [try] block, before any error handlers.  Conversely,
run finally blocks only from a matching handler down.  Does that make
any practical sense?

Also, would it make any sense to do it in the style of a C switch...
The handler body has to [break], otherwise it continues to try and
match.  For example, on a write error, you might want to send an error
message and flush.  Then if it's not a file closed error, send a
"connection closed" message, and flush.  Finally you'll close the
connection if it's still open, if there was any kind of error at all.
This would set [try] apart from any other TCL control structure, giving
it a unique niche that even catch+switch can't readily support.  Or
conversely, [continue] would cause it to keep looking, [break] would
prevent it from executing the finally block, and [return -code return]
could conceivably be used to alter the matching from here on down.


> Concerns:
> - How to handle "all other errors" (-like * would work, is that good 
> enough?)

Personally I'd like an "else" clause...  But "on *" would be good in
the presence of [continue] from above.  And with basic glob matching,
"handle *" could short-circuit and not even bother doing the match.

Your present concept of the matcher is broken.  It should not dictate
the source of the string being matched against, that's already done for
all normal usage cases, and the rest can be handled by [expr]-based
matching or almost certainly are better handled by an entirely
different structure.


> - No handlerscript may begin with a "-".

Sucky.  My plan puts options only before the match string.  If there's
no match string, then there's no options, either.


> - No feedback yet on "as {vars}" and the order of the vars

Sure you have.  I suggested something like that earlier, except called
"catch".  This is better.


> - If there are multiple handlers and one is unqualified, should it be 
> executed first or last?

In the name of least surprise, execute it where it stands.  That might
mask more specific ones further down, but it avoids magic.



Neil:
> Don't entirely agree with this. I don't believe we need to care
> about inconsistent sets of vars being defined after the try -- it's
> not a problem for [if], [switch], and every other control structure,
> so I don't believe we need to give it special consideration here.

It doesn't apply to [if] and most other control structures, and it only
applies to the [regexp] part of [switch], which is a very different
beast, as every single pattern has a different source of values for the
variables.


> Clarifying this -- we want the ability to specify the same script
> for multiple patterns (and possibly multiple exception codes). The
> switch approach is one way.

That can be done regardless.


> If adopting some novel pattern mechanism, then there is the further  
> question of whether to special case that in [try] or to extract it  
> out into a separate command (and separate TIP).

It's been needed for a long time.  Basic glob match for now, expand on
it once a decent mechanism is in place.


> I'd drop -llike -- too similar to -like, and the details of list  
> matching are complex to do right with nested sub-lists.  But that
> assumes all list elements are just strings (rather than e.g. being
> sub-lists themselves), so only partially addresses the issue.

In a general context, that would be a problem.  But is it expected to
be a problem for errorcode?  Sounds like the purpose of errorcode needs
revisiting, to figure out just what it is and isn't supposed to be,
because their seems to be some disagreement as to its complexity.


>> - No handlerscript may begin with a "-".  
> Which conflicts with the specification that "-" as a handlerscript  
> means fall-through to next branch.

Only if your handlerscript is a command called "-" which takes no
arguments.


> Overall, I think the proposal ends up with [try] doing too much. In  
> particular, it seems doomed to a linear trawl through various match  
> conditions. Specifying an overall match command and then passing it  
> all the patterns and handler scripts at once gives much more freedom  
> for efficient implementation.

I had the strange impression that a linear trawl through various match
conditions is exactly what we're doing.  It can be made a little more
intelligent by grouping based on code, and adjacent matches using the
same match type can be grouped by a [try] bytecode compiler (as DKF
pointed out just as I was about to click Send).


DKF:
> I feel that you're chasing off in the wrong direction. Try this:
>    try script ?as {msgvar optvar}? ?handler...? ?finally script?
> Each handler is one of these:
>    on code script
>    trap glob script

I hate to say it, but that's the basis of what I've been arguing for,
except that I added one extra handler type for OK (match on return
value for non-fatal failures), and the ability for code to have a
second word (again matched against the return value) for the regular
case of return codes >4.


-- 
Fredderic

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 46 days, 10:07)