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

[Neil M. <ne...@Cs...>]

On 23 Nov 2008, at 12:45, Twylite wrote:
> [...]
> 5. Proposal
>
> Based on this summary of the discussions so far, this is my current
> proposal:
>
>   try tryscript ?as {vars}? ?handler ...? ?finally finalscript?
>     where handler is
>   on code ?-matcher pattern? handlerscript
>     and
>   handlerscript may be "-" to fall through to the next handlerscript
>
> The tryscript is executed and the outcome (return code, result,  
> options
> dict) is captured into vars.  A fast match (possibly a dict lookup) is
> performed to find the handler(s) for that code.  If there is an
> unqualified handler (one with no matcher) or a single handler for the
> code, then it is executed; otherwise each handler is considered in  
> turn
> (left-to-right order) by calling the associated matcher, and the first
> matching handler is executed.  If no matching handler is found then  
> the
> exception is propagated.
>
> The implementation will probably provide the following handlers by
> default (users can implement their own):
>   - -like for glob matching against errorCode as a string (perhaps - 
> glob?)
>   - -llike for element-wise list-glob matching against errorCode as  
> a list

I'd drop -llike -- too similar to -like, and the details of list  
matching are complex to do right with nested sub-lists. You could  
just define it as:

   proc llike {pattern list} {
       foreach p $pattern item $list {
           if {![string match $p $item]} { return 0 }
       }
       return 1
   }

But that assumes all list elements are just strings (rather than e.g.  
being sub-lists themselves), so only partially addresses the issue.

>   - -expr for expr-based matching (with access to return code,  
> result &
> options dict)
>
> Example of use:
>
>   try {
>     # do stuff
>   } as {code em opts} on ok {
>     # do more
>   } on break - on continue {
>     # special handing for break & continue
>   } on error -like "POSIX *" {
>     # handle POSIX errors
>   } on error -expr { $em in {BAD FOO BAR} } {
>     # support legacy errors
>   } finally {
>     # cleanup
>   }
>
> Concerns:
> - How to handle "all other errors" (-like * would work, is that good
> enough?)
> - No handlerscript may begin with a "-".

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

> - No feedback yet on "as {vars}" and the order of the vars
> - If there are multiple handlers and one is unqualified, should it be
> executed first or last?
>
> Alternatives:
> - The body "-" is reserved to indicate fallthrough to the next body.
> The body "+" could be reserved to indicate that a matcher and pattern
> follow.
> e.g.
>   on error + like "POSIX *" { ... }

I don't understand how this + syntax differs from the -like "POSIX *"  
syntax.

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 take your point though that the pattern matching scheme is dictated  
by whoever produced the error more than whoever is catching it. My,  
this gets complicated. Frankly, I'd rather let one or more  
implementations sit in tcllib or elsewhere for a bit until it becomes  
clear what the best approach is. I.e., I believe experience in use is  
going to be crucial here, rather than trying to design from  
principles. I'd be surprised if we can settle a design in time for 8.6.

-- Neil

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.