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

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

Hi,
>> Concerns:
>> - How to handle "all other errors" (-like * would work, is that good
>> enough?)
>> - No handlerscript may begin with a "-".
> Which conflicts with the specification that "-" as a handlerscript 
> means fall-through to next branch.
No, just poor clarity on my part.  If the element under consideration is 
a "-" then it is a handlerscript (body) with the special meaning "fall 
through".  Otherwise if the element begins with "-" then it indicates a 
matcher, and the following elements will be an errorPattern and a 
handlerscript (body).
>> Alternatives:
>> - The body "-" is reserved to indicate fallthrough to the next body.
>> The body "+" could be reserved to indicate that a matcher and pattern
>> follow.
>> e.g.
>>   on error + like "POSIX *" { ... }
> I don't understand how this + syntax differs from the -like "POSIX *" 
> syntax.
Instead of reserving all handlerscripts starting with "-" (they will be 
treated as matchers), there will be exactly two reserved handlerscripts: 
"-" means falls through, and "+" meaning "this is not a body, the 
following three elements are matcher, errorPattern and body".
> Overall, I think the proposal ends up with [try] doing too much. In 
> particular, it seems doomed to a linear trawl through various match 
> conditions. Specifying an overall match command and then passing it 
> all the patterns and handler scripts at once gives much more freedom 
> for efficient implementation.
And that freedom makes the behaviour of the command uncertain from the 
users perspective.  Will each matcher consider the relevant handlers in 
left-to-right order?  Will each matcher execute the handler body in a 
consistent manner?
Bear in mind that this linear trawl only takes place when there are 
multiple handlers for the same return code -- matching exceptions 
(return code) is efficient.
> I take your point though that the pattern matching scheme is dictated 
> by whoever produced the error more than whoever is catching it. My, 
> this gets complicated. Frankly, I'd rather let one or more 
> implementations sit in tcllib or elsewhere for a bit until it becomes 
> clear what the best approach is. I.e., I believe experience in use is 
> going to be crucial here, rather than trying to design from 
> principles. I'd be surprised if we can settle a design in time for 8.6.
Unfortunately even in tcllib we aren't going to get much experience with 
this.  None of the other [try] extensions out there have received 
widespread adoption.

Regards,
Twylite