Re: [TCLCORE] Tcl-Core Digest, Vol 30, Issue 10

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

Twylite wrote:
> I still have concerns about this though:
> - The construct is getting pretty bulky - is it really adding power & 
> simplicity as it is intended to do?

Why are you using all of it at once? That's its most bulky case. (It's
also something that's quite a PITA to write with just [catch], speaking
as someone who's done that in the past...)

> - The "except" clause needs to be flexible enough to handle the expected 
> common use cases, but not so flexible/complex that it's easier to just 
> use catch.  There is little clarity on what the "common use cases" are.

So long as we can do multiple 'onerror' clauses and can omit the capture
variables, we'll be OK. (The errorinfo and errorcode can be picked out
of the options.) For the 'except' clause, it's probably only necessary
to be able to match the 'code' itself (and optionally capture message
and options, of course) while allowing the normal aliases for 0-4 (i.e. 
ok, error, return, break, continue).

It's possibly a good idea to forbid the trapping of 'ok' and 'error' 
using the 'except' clause; they have their own syntax.

The other thing is that the various trap clauses should be arbitrarily 
reorderable.

> - Often information about an error is implied in the result (as in 
> Tcl_SetResult) rather than an errorCode -- can except (or some other 
> clause) adequately handle this case?

Wrong question. The right question is "should it handle the case?" and I
think the answer is "no". Let's clean up the problems with critical info
not going into the errorcode instead (and I know that might take a bit).

> A modification I find particularly interesting is an alternative 
> approach to finally.
[...]
> Simple example of alternate finally syntax:
> try {
>   set f [open "myfile.txt" r]
>   finally [list close $f] ;# or finally { close $f } since it executes 
> in the context of the block
>   # ...
> }

I don't like that nearly as much, FWIW.

Donal.