Constants for catch return values?
Author |
Message |
MartinLembur #1 / 25
|
Constants for catch return values?
Hello,
http://www.*-*-*.com/ ), I saw, that the the error meaning return value of catch was stored in a variable, to know this value: | set ::TCL_ERROR [catch error] In C there are constants/defines for the possible tcl return values: * TCL_OK * TCL_ERROR * TCL_RETURN * TCL_BREAK * TCL_CONTINUE What's about a possibilty in tcl to get rid of the numerical values of catch, like there is no need while using the return option -code to remember the numerical values? What's about a dictionary or array inside the tcl namespace to access, no, more or less to reference the numerical return values? | namespace eval ::tcl { | array set errorCodes [list \ | ok 0 \ | error 1 \ | return 2 \ | break 3 \ | continue 4 \ | ]; | }; Or what's about letting catch return (optional) a tokens (ok, error, return, break, or continue) instead of a numberical value (0-4)? I know, I can do this on my own in my applications, but I start this thread, because I think that there is an inconsistence between the tcl command return and catch and the handling of return values. Thanks for any thought, comment, etc.! Best regards, Martin Lemburg UGS - Transforming the Process of Innovation
|
Sat, 28 Jun 2008 19:17:24 GMT |
|
|
Gerald W. Leste #2 / 25
|
Constants for catch return values?
Quote:
> ... > Or what's about letting catch return (optional) a tokens (ok, error, > return, break, or continue) instead of a numberical value (0-4)?
This would break way too much existing code. One of the features of Tcl has been its high backward compatibility.
|
Sat, 28 Jun 2008 21:41:55 GMT |
|
|
MartinLembur #3 / 25
|
Constants for catch return values?
Hello Gerald, sorry but I do not agree! In tcl 8.5 we extended catch to allow a new optional parameter: | catch script ?resultVarName? ?optionsVarName? Why not a syntax like this: | catch ?-tokenize? script ?resultVarName? ?optionsVarName? Only if a script starts with "-\S" (RE) than a backward compability would break. Or to be much more tolerant, but not really tcl like (see switch) ... if the first argument is not equal to "-tokenize", than it's the script to be evaluated, but only if the count of arguments is not greater than 3! We discuss sometimes matters about tcl 9.0 and some people try to restrict language development to be always backward compatible, but some things are perhabs better after breaking this compability. In this case of the tcl command catch, I don't see really a real backward compability problem. Best regards, Martin Lemburg UGS - Transforming the Process of Innovation
|
Sat, 28 Jun 2008 21:57:51 GMT |
|
|
Gerald W. Leste #4 / 25
|
Constants for catch return values?
Quote:
> Hello Gerald, > sorry but I do not agree! > In tcl 8.5 we extended catch to allow a new optional parameter: > | catch script ?resultVarName? ?optionsVarName? > Why not a syntax like this: > | catch ?-tokenize? script ?resultVarName? ?optionsVarName? > Only if a script starts with "-\S" (RE) than a backward compability > would break. > Or to be much more tolerant, but not really tcl like (see switch) ... > if the first argument is not equal to "-tokenize", than it's the script > to be evaluated, but only if the count of arguments is not greater than > 3! > We discuss sometimes matters about tcl 9.0 and some people try to > restrict language development to be always backward compatible, but > some things are perhabs better after breaking this compability. > In this case of the tcl command catch, I don't see really a real > backward compability problem.
Adding the -tokenize switch would preserve +99% backward compavility. Sorry, did not think about that in the original posting. Why don't you TIP this?
|
Sun, 29 Jun 2008 04:06:47 GMT |
|
|
Neil Madde #5 / 25
|
Constants for catch return values?
Quote:
> Why not a syntax like this: > | catch ?-tokenize? script ?resultVarName? ?optionsVarName?
Why a new option when a new command will serve you just as well: proc exceptiontype code { set tokens [list ok error return break continue] if {$code < 0 || $code > [llength $tokens]} { return $code } else { return [lindex $tokens $code] } Quote: }
switch -exact [exceptiontype [catch ...]] { ok { ... } error { ... } Quote: }
Commands are compositional (the big win of language), options are not. Such an [exceptiontype] command has the potential for reuse, an option is a special purpose piece of functionality. -- Neil
|
Sun, 29 Jun 2008 04:58:46 GMT |
|
|
MartinLembur #6 / 25
|
Constants for catch return values?
You are right Neil! Why not a command like yours exceptiontype?! Just for one reason - if a programming language is alive, if enough people think that it lacks something, than this issue has to be solved. For sure, everybody can provide is own resolution for many issues. But here, it is about tcl internals! Programming with the tcl C-API, I never care for the numerical return values! I always use the defines, like e.g. TCL_ERROR. Programming within tcl using the command return I never care for the numerical return values! I always use the defined tokens, the replacements for the numerical return values, like e.g. error. But using the command catch I always get numerical values and I have to know the numerical representation of an "error" or "break". There is no need for, and in my eyes this is a design "issue". To solve this nobody should be forced to write a proc, to copy a proc from the wiki into a package, to change the tcl library to contain such a proc, etc.. It's about the language itself, which has to provide this support to mask internal values with tokens at mostly every place where those internal values occur, like already done in the return command. That's the reason, why I asked for a discussion about this "issue"! Not because I'm not able to create a selfmade, company or unique, evt. "personal" resolution for this "issue"! Best regards, Martin Lemburg UGS - Transforming the Process of Innovation P.S.: Sorry, if the reply sounds harsh! I hope you don't feel flamed!
|
Sun, 29 Jun 2008 17:33:40 GMT |
|
|
MartinLembur #7 / 25
|
Constants for catch return values?
Hello Gerald, I think about it, about to TIP this. I'll take a look at the 8.5 sources, of the catch command and ... - we'll see. Best regards, Martin Lemburg UGS - Transforming the Process of Innovation
|
Sun, 29 Jun 2008 17:45:53 GMT |
|
|
suchenw #8 / 25
|
Constants for catch return values?
I think [exceptiontype] is less generic than it could (and should) be, how about doing it like this: proc listmap {list index} { set res [lindex $list $index] expr {$res eq ""? $index: $res} Quote: }
interp alias {} exceptiontype {} listmap {ok error return break continue} 236 % exceptiontype 0 ok 22 % exceptiontype -1 -1 27 % exceptiontype 4 continue 23 % exceptiontype 5 5
|
Sun, 29 Jun 2008 18:01:18 GMT |
|
|
Neil Madde #9 / 25
|
Constants for catch return values?
Quote:
> You are right Neil!
Thanks! Quote: > Why not a command like yours exceptiontype?! > Just for one reason - if a programming language is alive, if enough > people think that it lacks something, than this issue has to be solved.
The point wasn't that the functionality shouldn't go into the core (although, I don't think it should) but that implementing it as an option (i.e. a special way of modifying the behaviour of a single command) is the wrong way. Better to implement it as a command so that it can potentially be reused (e.g. see Richard's elegant 2 line generic version). Quote: > For sure, everybody can provide is own resolution for many issues. > But here, it is about tcl internals! > Programming with the tcl C-API, I never care for the numerical return > values! I always use the defines, like e.g. TCL_ERROR. > Programming within tcl using the command return I never care for the > numerical return values! I always use the defined tokens, the > replacements for the numerical return values, like e.g. error. > But using the command catch I always get numerical values and I have to > know the numerical representation of an "error" or "break". There is no > need for, and in my eyes this is a design "issue". > To solve this nobody should be forced to write a proc, to copy a proc > from the wiki into a package, to change the tcl library to contain such > a proc, etc.. > It's about the language itself, which has to provide this support to > mask internal values with tokens at mostly every place where those > internal values occur, like already done in the return command.
But Tcl already *does* provide a means to do this, as I pointed out on the wiki (and you quoted at the start of this thread) [catch] will itself let you hide the return code values: set rc [catch { ... } res] if {$rc == [catch error]} { # handle error Quote: } elseif {$rc == [catch break]} { # handle break } elseif {$rc == [catch return]} { ... etc ... }
-- Neil
|
Sun, 29 Jun 2008 19:57:19 GMT |
|
|
MartinLembur #10 / 25
|
Constants for catch return values?
Hi Neil, thanks for your reply! Quote: > The point wasn't that the functionality shouldn't go into the core > (although, I don't think it should) but that implementing it as an > option (i.e. a special way of modifying the behaviour of a single > command) is the wrong way. Better to implement it as a command so that > it can potentially be reused (e.g. see Richard's elegant 2 line generic > version).
I'm not of the opinion, that in this case a new command or procedure is a better solution, than a new option to change the behaviour of this command. But this may be a more philosophical, than a technical discussion, because my main point was to hide internals and to make it easier to work in a congruent way with return codes. But in the end your code example (if structure testing against [catch ...]) made me struggle, because ... you are right! There is already a command to translate a return value token back into a return value! Even if the return value token is not really a token, but the name of a corresponding command! I think I'll adapt this code pattern, but ... really I'm not really satisfied with it. Best regards, Martin Lemburg UGS - Transforming the Process of Innovation
|
Sun, 29 Jun 2008 20:29:54 GMT |
|
|
Donald Arsenea #11 / 25
|
Constants for catch return values?
Quote:
> | catch ?-tokenize? script ?resultVarName? ?optionsVarName?
What would be the proposed handling of return -code 42 "The answer" ? --
|
Sun, 29 Jun 2008 20:45:25 GMT |
|
|
MartinLembur #12 / 25
|
Constants for catch return values?
Hello Donald, I would say, something that can not be tokenized, a catched return value, that is out of the range of tcl internal return values, should be returned without modification. If I think more complex, than an application could perhabs register new return codes (values and corresponding tokens), so that catch may look after a matching return code and return the corresponding token. The main problem, why I didn't mention it before, is, that 3rd party packages may have problems with this. Package A expects the return value 42 to be "theAnswer", but package B thinks 42 must be "whatWasTheQuestion". A conflict I don't want to guilty for! Richards procedure to return a value of a list - if indexable - or the index - if out of range - answers your question, because that was the not telled, but expected behaviour. Best regards, Martin Lemburg UGS - Transforming the Process of Innovation
|
Sun, 29 Jun 2008 21:04:39 GMT |
|
|
Fredderi #13 / 25
|
Constants for catch return values?
On 11 Jan 2006 04:29:54 -0800, Quote:
> > The point wasn't that the functionality shouldn't go into the core > > (although, I don't think it should) but that implementing it as an > > option (i.e. a special way of modifying the behaviour of a single > > command) is the wrong way. Better to implement it as a command so > > that it can potentially be reused (e.g. see Richard's elegant 2 > > line generic version). > I'm not of the opinion, that in this case a new command or procedure > is a better solution, than a new option to change the behaviour of > this command.
I rather agree. We have [return -code break], so why should [catch] return a numeric code? I for one can never remember which is break and which is continue. I know they're 3 and 4, but I ALWAYS have to check the docs to see which is which. And what's worse, the main docs I use don't actually say it, so I have it written down in a little note file. Plus conversion from a numeric into a string on the existence of a switch would likely be dirt-cheap to implement right there within the [catch] command. And vastly cleaner to read than having to wrap it in another function call. Especially when you're also involving [uplevel] and other such uglies. I'm all for a nice clean "-token(ize)" option! Fredderic
|
Mon, 30 Jun 2008 00:19:20 GMT |
|
|
Fredderi #14 / 25
|
Constants for catch return values?
On 11 Jan 2006 04:45:25 -0800, Quote:
> > | catch ?-tokenize? script ?resultVarName? ?optionsVarName? > What would be the proposed handling of > return -code 42 "The answer"
Why is that an issue? You can't specify the 42 by any other means, so what does it matter if catch simply returns it as-is? And if [return -code] is extended to accept names for other values, then so would [catch -tokenize] be extended to return them. Fredderic
|
Mon, 30 Jun 2008 00:24:25 GMT |
|
|
Donal K. Fellow #15 / 25
|
Constants for catch return values?
Quote:
> Why is that an issue? You can't specify the 42 by any other means, so > what does it matter if catch simply returns it as-is? > And if [return -code] is extended to accept names for other values, then > so would [catch -tokenize] be extended to return them.
Each different -code should have distinct semantics, and the other parts of the return system should be used to disambiguate them further if that is so needed. Thus, 0 indicates success, 1 indicates error (and causes a trace to be built), 2 indicates 'return' with all the handling of the -level parameter that that implies, and 3 and 4 have very specific meanings for things like loops... :-) But what should these other values mean? Should we just have a single new number (5) that indicates 'exception' and require people to use, say, the errorCode value to disambiguate? (I suggest that because that's intended to be a machine-readable list.) Oh, the other tricky bit is that the space of error codes is universal across all interpreters. :-) Donal.
|
Mon, 30 Jun 2008 07:36:02 GMT |
|
|
Page 1 of 2
|
[ 25 post ] |
|
Go to page:
[1]
[2] |
|