Is there a convenient way to see tempvars while debugging an ado program?

[Jesse Wursten]

I am currently trying to add a new error check to my xtistest command, however debugging it is proving rather hard because I can't see the contents of the tempvars and so on. Is there any functionality in Stata that makes this simpler?

[Nick Cox]

Suppose you created

tempvar foo 
gen `foo' = 42

While that variable exists, you can apply standard commands to it. Opening the editor to see it is often futile because it disappears when the program terminates, but

list `foo' 
summarize `foo' 
tab `foo'

are all possible debugging commands.

[Jesse Wursten]

Hmm, that's unfortunate (the debugging would be a lot easier in my case if I can see all the data in the editor), although not unworkable. Thanks!

[Robert Picard]

To be able to view the content in the editor, you must be able to stop the execution of the program. To make a program break at a particular point, force an error. I usually use

exit 99

Of course the temporary variables will vanish before you are able to inspect their content. A workaround is to rename them. For example:

sysuse auto, clear
tempvar foo
gen `foo' = cond(mi(rep78), rep78[_n-1], rep78)

* force a break and make foo permanent
rename `foo' foo
exit 99

* rest of code here

[Jesse Wursten]

I ended up generating the variables I needed followed by an error (see below), although renaming them might actually be a neater solution (easier to spot where you meddled with the code, as you generally don't rename much in ado files).

gen foo = `foo'
error 1

Which eventually did the trick, although removing the code again afterwards was a bit annoying (I missed bits quite frequently). It would be great if it similar functionality could be added as an option to set trace on. As in, if trace is on, then whenever a tempvar is declared, it is generated as a normal variable instead. It would probably make sense to still call them _00001 and so on and use the name given as a variable label, to avoid situations where the variable was already present.

[Nick Cox]

Debuggers are easy to dream of, but harder for developers (not us) to write well. The more they show, the more they show largely what turns out to be irrelevant. It seems a fact in debugging that you have to pepper your own code with customised extra statements to show any possible culprit before your dopey mistake becomes obvious.

[Roger Chu]

You could also use the command pause to help you debug. pause will let you pause execution of the do-file, execute some commands from the keyboard, and then restart execution. Because you're pausing your do-file in the middle of execution, tempvars will not have been deleted yet, so you can easily browse through them in the data browser.

A way to use pause would be to call it right at or after your point of issue in your do file so that you can then scroll through the tempvar to see what's going on.

For more info...

help pause

[wbuchanan]

I agree with Roger Chu and this is the method I tend to favor since I can display a message telling me what specifically to look for when the program pauses in the middle of execution.

[Jesse Wursten]

Always great when you find a thread you started yourself when googling a problem. #somepeopleneverlearn

[wbuchanan]

It can also help to assign the tempvar a variable label with the name of the tempvar. This way if you use pause you don’t need to worry about trying to decipher the more cryptic temporary variable names that Stata assigns automatically.

[Attaullah Shah]

Normally, I just save the data set after creating the temporary variable. This way, the temporary variable and all other variables are saved at that time before they cleared from the memory.

tempvar myvar
gen myvar = 'some expression'
save temporary_save, replace

And then I can go back to open the temporary_save file and see all the variables there.