This is not necessarily the current version of this TIP.
|Title:||Substituted 'errorstack' / 'traceback'|
|Version:||$Revision: 1.16 $|
|Author:||Alexandre Ferrieux <alexandre dot ferrieux at gmail dot com>|
|Created:||Thursday, 26 February 2009|
This TIP proposes to add an errorstack options dict entry and associated info subcommand, giving a "substituted" traceback similar to Python's or gdb's ones.
The ::errorInfo variable is a valuable tool for debugging; however, it yields mostly static information regarding each level of procedure call, as it only gives the static text (extracted from the source) at the call site. This leads to frustrating situations, like when an error occurs at a deep level of a recursive function, ::errorInfo repeatedly reporting "f $x [foo [bar]]" or similar un-substituted commands. In other languages, the traceback is more useful in that it contains the actual values passed as arguments.
This TIP proposes to create an -errorstack options dictionary entry, and an associated info errorstack ?interp? command returning a list containing the [info level 0] lists of command-and-args at each stack frame level at the time of error unwinding.
In a natural implementation, its construction is analogous to that of ::errorInfo, which is built incrementally, one level at a time while popping back from the error site. The only differences are that:
dynamic arglists (from [info level 0]) are stored,
the result is a true list built by (the equivalent of) lappend, and
the granularity is coarser than with ::errorInfo since there is just one element per stack frame level (and not for intervening while or foreach constructs) and no adornment like "... while executing ..."
Measurements show that the performance hit of maintaining the error stack is small, being under 5% for realistic error stack sizes, and hits only the error cases. To achieve this speed, the list-growing is done carefully, reusing ea