A StackTrace is a very helpful debugging tool. It shows you the call stack (meaning, the stack of functions that were called up to that point) at the time an uncaught exception was thrown or the time the stacktrace was generated manually. This is very useful because it doesn’t only show you where the error happened, but also how the program ended up in that place of the code.
In other words, a stack trace allows tracking the sequence of nested functions called up to the point where the stack trace is generated. In a post-mortem scenario this extends up to the function where the failure occurred but was not necessarily caused.
Error debugging with StackTrace
The function test.stackTrace() returns a list of stack frames representing active function calls.
The first element (0) in the list contains information about the location of the test.stackTrace call itself. The second element (1) contains information about it’s caller and so on. The last element (2) in the list is usually the main function call.
Each stack frame value in the returned list features following fields:
fileName: The name of the source file in which the function call was done.
line: The line number in the script file in which the function call was done.
startFrameIndex and maxFrameCount
test.stackTrace (startFrameIndex, maxFrameCount)
When the startFrameIndex parameter (number) is set, the given number of most recent frames will be skipped. This is especially useful for retrieving stack traces from framework functions in which case, the stack trace should possibly not include the code internal to the framework itself. If the parameter is not given the defaults is zero or in other words, no frames are skipped.
If both startFrameIndex and maxFrameCount are set, the stack trace will also be be limited to maxFrameCount frames. It will not be computed all the way back to the initial call to the main function which can improve performance for deeply nested script frameworks.