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

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

On 23 Nov 2008, at 17:06, Twylite wrote:
> Hi,
>> 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. Agree though that it is generally more useful  
>> for whatever pattern matching mechanism is used to be called with  
>> a set of pattern/script pairs and the variables already set-up in  
>> the callers scope. Whether that means binding the vars for the  
>> entire try statement or once per exception code is a matter of  
>> choice. Either seems acceptable.
> The difference being that in the case of [if] or [switch] the  
> executed body defines the vars; in this case the [try] itself  
> defines the vars.  Semantics.

I don't think that actually matters. In what circumstance do you  
envision this causing a real problem?

> The stronger argument is the performance impact of bringing per- 
> handler vars into scope and back out of scope each time.

I don't see this point, could you elaborate? The vars only need to be  
defined once.

>>> (e) A [switch]-like "fall through to next statement" would be a
>>> nice-to-have.
>> 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.
> Cool.
>>> 3. Matching
>>> (b) When matching against errorCode:
>>>   (i) There is (largely) consensus that basic pattern matching is  
>>> "good
>>> enough" "for now".  Basic pattern matching may be defined as prefix
>>> matching, glob matching against errorCode (as a string), or an
>>> element-wise list-glob match against errorCode (as a list).  In  
>>> short
>>> there is no agreement on the right way to do this.
>> 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).
> So that we have [catch], [try], [try2], ... as we discover new and  
> different needs for exception handling?  No thanks.  We should  
> either get [try] sufficiently right now (which is closer to 99%  
> than 80%) or make it extensible.  Preferably the latter since we  
> don't know what is 99% right.

No -- I mean you would have [try] and some [lmatch] command.

>>> [...]
>> I don't believe [try] has to execute the bodies. All it has to do  
>> is ensure that any option/result variables are defined in the  
>> calling scope when that script runs. For example:
> There are a bunch of other things [try] has to do, including  
> catching errors off the handlerscript (and match command, for that  
> matter) in order to chain the errors, execute the finally script,  
> etc.  Having the match command execute the body means that its not  
> just a match command but a fully fledged control structure, it must  
> behave in a way that is predictable to the [try] command (i.e.  
> [try] needs to make certain assumptions about what it will do), and  
> the [try] cannot distinguish between a failure in the match command  
> and a failure in the handlerscript.

I don't see why [try] has to know anything at all about it. It is  
just passed a callback that takes the errorcode and a list of pattern- 
 >script pairs, and simply calls it, returning whatever it returns  
(including exceptions). All it needs to do is ensure any "finally"  
script runs.

> It also has the potential to make the errorInfo very ugly -- you  
> will see an exception in a handler in a matchcommand in a try.  If  
> you try to use a [return -level] to avoid this you will end up with  
> unsafe nesting and/or making assumptions about the internals of [try].

I don't see this as a problem. If [try] is documented as delegating  
to a match command then it makes sense for that command to appear in  
the stack trace. [try] can always pretty up the errorinfo if it helps.

> In your proposal you also talk about the match command adding a  
> default -- this would not work if [try] is expected to chain  
> errors, as [try] would catch the default (assumedly rethrown) error  
> and chain it to itself (i.e. the error that [try] knows about).

A simple equality check would avoid this (a Tcl_Obj pointer  
comparison). Alternatively, the default script can be manufactured to  
signal this special condition. It's a problem of implementation not  
interface.

> Any way I look at it, having the match command execute the body  
> joins together separate concerns (matching, and execution), and  
> there are only two arguments for this:

Yes, you can separate these concerns, of course. But neither of them  
need to be handled by [try].

> (1) Performance.
>
> The largest number of exception handlers I've ever seen attached to  
> a single try is 5 or 6.  It there ever going to be a large enough  
> number that the performance difference will be significant?

Possibly, in generated code. E.g. there are quite a large number of  
possible HTTP return codes. If these got put into an errorCode {HTTP  
302 /redirected.html} then I can quite imagine HTTP client libraries  
wanting large try statements and wanting fast lookup.

> (2) Specifically allowing the order of matching to be determined by  
> the match command.
>> I also believe the order in which to consider patterns should be  
>> left to the match command.
> I think non-determinism in the syntax of a language is a very bad  
> thing.  Notice that even [switch] is documented as: "The switch  
> command matches its string argument against each of the pattern  
> arguments in order", so the behaviour is deterministic and  
> unsurprising from a user perspective, and a linear trawl would be  
> no slower than a matcher that uses [switch]. In order to ensure the  
> performance of the "common case" the most common matcher (probably  
> "-like") could be hard-coded into the [try] implementation.

This is the point -- the behaviour isn't non-deterministic as it is  
explicit what command is being used for matching, and the docs for  
that command specify the ordering used. Non-determinism doesn't  
require that [try] specify every last detail of execution -- it can  
happily delegate those responsibilities.

-- 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.