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

[Andreas L. <av...@lo...>]

On Tue, Nov 25, 2008 at 12:57:57PM +0000, Donal K. Fellows wrote:
> Andreas Leitgeb wrote:
> >One point of "try" and it's error-filtering is to make all unhandled
> >exceptions fall through, run the finally block and then get rethrown.

> The way in which [try] works has got to be this:
>   set code [catch $firstbody $msgVar $optVar]
>   set handler [pick handler based on $code [set $msgVar] [set $optVar]]
>   set code2 [catch $handler msg2 opt2]
>   eval $finallybody
>   if {$code2 != 0} {
>      set code $code2; set $msgVar $msg2; set $optVar $opt2
>   }
>   return -code $code -options [set $optVar] [set $msgVar]

Ok, that mutes some doubt I had.  Anyway, nested switches would need
to explicitly re-throw errors not handled.  Not a big issue, but it
shrinks the advantage of [try] against old [catch {...}].

> All that is missing is the code to actually pick the handler script,
> which in turn should be kept simple as well.
> >PS: Is it really that hard to call non-inlined matcher-commands from
> >  generated bytecode?
> 
> It's even more trivial to compile a script. Guess what? You can just put
> that stuff in the script in the first place.

Well, you said, that bytecoding a more advanced matcher/picker would be
exorbitantly more complex, so I wondered if calling out to a separate
command to do the picking wouldn't help to prevent that exponential
explosion of effort bytecoding a saner check.

> So why do we need a generalized matcher architecture?
> Answer: We don't. So why are you developing one?
Here is a little difference between me and Fredderic.

I do not primarily envision all those pluggable handlers, but
I'm very unhappy with using glob-matching on lists(*). Since I do
not see any chance to stop that particular train heading wrong
direction, I do hope for some spare rails that would at least 
allow the next train (8.7 or so) to go in a better direction,
while not derailing this current train on its trip.

*:
I really thought the paradigm was to *reduce* the number of
places where lists are stringified...

If you think, that embedding switches is a good idiom, then 
why not just match the [lindex $errorCode 0] with a glob or 
even exactly, and leave further matching to embedded switches?
Still better than globbing a list, imho.

> Not "astronomer", "astronaut". With reference to
>  http://www.joelonsoftware.com/articles/fog0000000018.html
Ok, this definition doesn't suit me that well.  I may lose
ground with some visions, but hardly ever for high abstractions.