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

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

Twylite wrote:
> OTOH I've had a stab at writing the synopsis line for the man page, and 
> the bulkiness/complexity is not funny.

Can't be helped. It's not as bad as [lsearch] or [canvas]...

> As currently specified you would use "onerror {glob ?emvar? ?optsvar?}", 
> but if you omit emvar/optsvar then you have no access to this 
> information within that handler.

Sounds acceptable to me. If people want the info, they'll capture it.
OTOH, they might be quite happy without. (For example, if trapping a
particular POSIX error from [open].) The only real question is whether
the msgvar and optvar should be that way round. Pass on that! :-)

>>> - 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).
> The problem with that approach is that it forces a workaround (via 
> 'catch' or an 'except' handler) when integrating with legacy 
> code/components that are naughty.

Can't be helped. If one bends over backwards too far, one falls over and
fail to achieve one's goals. I think this is one of those times...

>>> A modification I find particularly interesting is an alternative 
>>> approach to finally.
>> I don't like that nearly as much, FWIW.
> I'd be interested in reasons/insight?

It doesn't feel right. Yeah, I know that's not the strongest of points,
but I think it's probably based on the fact that most users^Wprogrammers
are *very* confused by the whole idea of out-of-order execution. They
find [after] and [fileevent] difficult. [bind] too. :-\

Donal.