Re: [TCLCORE] TIP #329 [try] updated

[Twylite <tw...@cr...>]

Hi,
> Donal K. Fellows wrote:
>   
>> Andreas Leitgeb wrote:
>>     
>>> A few minor questions about implementation (I'm just curious):
>>>   How does the byte-coded "lrange" thing deal with bad lists
>>>     (i.e. something like "{fsg fds}dsfa {" ) ?  The  TIP specifies
>>>     that no errors be thrown for non-list errorCodes or patterns.
>>>       
>> Ooops, missed that. I'll change that when I call the vote because it's
>> not a good decision. The list interpretation of error codes has been
>> assumed for well over a decade, so a non-list error code is an error itself.
>>     
>
> If you rephrase it, please ensure that the new text
> continues to specify that in the following:
>
> 	} on error {msg opts} {
> 	    # (2)
> 	} finally {
> 	    # (3)
> 	}
>
> clauses (2) and (3) are executed.
>   
Thanks Joe - I didn't get a chance to response to Donal yesterday. 
What I said (or intended to say) in the TIP was that the [try] itself 
must not die horrible if it encounters an errorcode that is not a list.  
This would imo be a bug in [try] unless error/return/throw force their 
errorcode argument to be a list (which they don't).  And it would be a 
Bad Thing because then someone doing something stupid lower down the 
stack can blow up your anti-blowup control structure.

Two ways of handling this:
(1) If errorcode is not a list, then trap handlers must determine that 
there is no match, and let the error fall through to the next handlers 
and be processed or propagated as normal.  I _think_ that's what Donal's 
rewrite is saying, but I'm not certain?
DKF - can you confirm this?

(2) Update the implementations of error & return so that a non-list 
error code raises an appropriate error at that point, rather than 
allowing arbitrary strings that can blow up the [try] later.

Regards,
Trevor