Finally, the author needs to address the problem, which typically involves following the same process upstream in the code to find the line where the incorrect input is being generated. Next, the author must determine why the input to that line is different than what they had anticipated, which typically involves inserting a pause or display command to assess the state of various memory elements at that point. This is usually done with trace or display.
First, the author must determine where the issue is occurring, by finding the literal line of code that is producing the error or unexpected result. For example, a loop that includes conditional statements or data subsetting may result in empty datasets or undefined macros or expressions and cause later code to be invalid.ĭebugging Stata code follows a three-step process each time such an issue is encountered. Typical examples occur when code is generalized or looped such that code that is written or tested in a given environment is then applied to situations where it was not originally envisioned or tested. Such a bug usually results from an intermediate state arising from a complex combination of code, which is not easily foreseeable when writing the code. When code execution produces errors or unexpected results, it is typically very difficult to determine what is causing an issue simply by looking at the code and results.
(Alternatively, exit can be used to simply halt execution in place, although this will not work in some circumstances, such as when preserve is active.) While paused, Stata allows the user to interact with the data as it is at that point in code execution and to permit code execution to continue when finished.
#QUIETLY STATA HOW TO#
Understanding how to use these tools interactively will allow you to pinpoint and correct errors in code. Stata code is typically debugged using four tools: trace, pause, display, and capture.