Re: try command error codes, where documented?

On 8/19/2024 1:01 AM, Harald Oehlmann wrote:

Am 17.08.2024 um 09:09 schrieb et99:

On 8/16/2024 9:45 PM, greg wrote:

Am 16.08.24 um 20:28 schrieb et99:

Is there a good place to lookup the various error codes returned by tcl commands?

..snip

Thank you for the words and the initiative.
Reality is worse. We are on 3 platforms.
So, we try to get the same error code on all of them.
Errors come often from system calls. On Posix systems, they are just put up to the script. On WIndows, Windows error codes are mapped to possix error codes, which works more or less...
 Remark that error codes are also available by catch.

I see the problem. However, many tcl command manual entries have sections describing differences between systems. If error codes are different, that would be an appropriate place to document that as well.
I was thinking about the leverage one would have if all the error codes were documented in one place. By them not being easy to find, I just take the lazy course and use catch and write out whatever error message the catch returns. If they were documented once, then (all) programmers would have an easier time.

 The advantage of try is that you have a cleanup case, which is always executed, even on error and on return.
 so:
 proc t {fn} {
try {
set f [open $fn]
set d [read $f]
return $d
} trap ...
} on ...
} finally {
     if {[info exists f]} {close $f}
}
}
 Closes the file in any handling case. It is beautiful, that the finally happens after the return command and the return still works.
 This is a constructed example. But it might be handy.

This finally behavior I had not known. It also seems quite remarkable to me since ordinarily once a return statement is executed, the stack frame would be expected to be popped and so that variable f would no longer be accessible. Clearly try must be doing something special if it can execute code after a return command.
I just re-read both return and try manual pages and I cannot find anywhere that mentions this behavior explicitly with a return command. Frankly, this seems like a good way to create a lurking bug.
It reminds me of the C code gotcha where a programmer added the andthis w/o realizing the scope of the if statement:
if(boolean)
   dothis;
   andthis;
-e