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

[Colin M. <co...@ch...>]

Magentus wrote:
> - And for cleaning up those messes of switch and other statements
> presently needed to support all kinds of error and result handling.
> If done right, it'll be fast and efficient for the simple case.  And
> a heck of a lot easier to read and work with in the complex case.
>
> Especially when it's so damn simple trivial to do so much better.
>   
I don't see 'trivial', and I don't see 'better', in what's been proposed 
here at various times.

I presume you're talking about [switch] being messy when it's used to 
decode error conditions.  I see nothing messy about [switch]ing on 
conditions to discriminate different cases of error and take appropriate 
actions.  Error conditions aren't somehow special, they're just more 
data to be processed, and if [switch] isn't an appropriate way to 
represent discrimination between cases, then that's a problem with 
[switch] which should be analysed.  I see no problem with [switch], and 
I've seen no reports of any discomfort with [switch] in the role of case 
discriminator.

The proposals I've seen would not be 'easier to read or work with', they 
obfuscate the processing required to properly handle errors by wrapping 
it in a gigantic command with so many options and internal argument 
syntax it may as well be another language.  I can't name another such 
complex command in tcl core.

About the only valid complaint I've seen about [catch] which doesn't 
rely upon the questionable premise of error data being somehow 
privileged is that it requires the use of temporary variables.  I think 
this would be handled by a variant of [catch] which returned a dict 
whose values could then feed a [switch].  You can use string 
concatenation to test for error code, combine that with whatever you 
want to handle the error data returned in dict form.

Arguments that error processing is complex and that it therefore 
requires a special kind of processing are specious.  Any argument you 
can make that an error dict requires special processing should properly 
apply to absolutely any dict - the fact that the dict happened to be 
derived from an exception is immaterial.  If someone made an argument 
that there needs to be a special tcl core command to handle (for 
example) processing a database record qua dict because 'handling 
database records is hard, and there's some messy code out there to do 
it' I doubt it'd even get to TIP.

Colin.