One of the more frustrating experience that I have endures while developing applications in Tcl is that of trying to find bugs in code that consists of many procedure modules which call each other. A single statement error, such as an invalid expression, causes an error message that tells one nothing about the probable location of the error. I am then forced to read each line of the code in the possible execution path to try to locate the statement that actually caused the error. Of course, there are tools to help, such as the Tkcon console, the Tcl debugger, and the use of the bg_error command and the unknown command. Since I use a programming style that consists of developing a large number of 5 to 10 line procedures, which I then build into an application, I am able to use the following artifice to tell me immediately where an error occurs: !!The call Procedure The call procedure is a simple one with the following lines of code: proc call { what args } { if { [catch { eval $what $args } result] } { puts stderr "Procedure \"$what $args\" failed because : $result" } return $result } This procedure will trap the error message from any procedure call and print out the name of the procedure, its arguments, and the reason for the failure. If there is no failure, the result returned from the called procedure is returned without comment. !!Implementation Every time I invoke a procedure, I use a statement of the form: call Myproc arg arg ... as in, for example, set result [call Myproc $a $b $c] Now, if Myproc, or one of the functions that it calls, fails, then I get the name of the failed procedure, its arguments at the time of failure, and the error message. It is usually a lot faster to debug the specific failed procedure than it is to re-check a large chunk of code. Of course, some programmers still believe that the way to write procedures is to have one proc with thousands of lines of code. If you are of this school, this method is quite useless. !!For the Critics Indeed, this method adds overhead to your script. It does, in my experience, considerably reduce development and debugging time, however, and I believe that any loss of efficiency in execution is of secondary importance, considering that everyone is buying 3.0 Ghz boxes these days. And yes, I am a one time FORTRAN programmer, so the syntaxtic style comes naturally!