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

[Donal K. F. <don...@ma...>]

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 'finally' block gets run in all (trappable) cases.

> What would be the standard idiom with "switch inside a handler body",
> to get this behaviour from the switch's default block? 

You use [return] with right options to rethrow an exception, but you
also only trap the stuff that is appropriate in the first place. None of
which has anything to do with 'finally' processing.

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]

Or something like that. I've spent as long on that as it took to type.
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. So why do we need a
generalized matcher architecture? Answer: We don't. So why are you
developing one? (That's the part I find hard...)

> PPS: I do also feel addressed by "astronomer", and I don't feel
>   insulted by this classification in this context.

Not "astronomer", "astronaut". With reference to
  http://www.joelonsoftware.com/articles/fog0000000018.html

Donal.