When a do-file fails

[Esteban Jara]

Hello. I am looking for some option of the "set" command (if this option exists) that indicates, when executing a do-file, in which line of the do-file is the error that caused the do-file to crash. Does anyone know if this can be done? Thank you

[Jared Greathouse]

Not possible (I don't think). Why doesn't the Stata terminal tell you where the code failed, though? It does show up on your screen, right, unless you're running it quietly...

[Clyde Schechter]

It does show up on your screen, right,...

In general, yes. But if the code fails inside a loop structure, the error message appears before the entire loop, with no indication of which command within the loop threw the error. Sometimes the error message could only have arisen from some particular command, but if the error message is something more generic, then you can't tell where things went awry.

The only solution I know if is to -set tracedepth 1- and -set trace on- at the top of the loop. That will make Stata echo each command to the Results window as it proceeds through the loop. But it also causes Stata to show all of the output from those commands--which may not be desirable.

...unless you're running it quietly...

Actually, -quitely- does not suppress error messages. Only -capture- does.

. sysuse auto, clear
(1978 automobile data)

.
. capture regress price mpg in 1

.
. quietly regress price mpg in 1
insufficient observations
r(2001);

[Esteban Jara]

It's funny that there is no such option. Doesn't it happen to you that in a do-file of hundreds of lines, when the do-file crashes it's hard to find the line that caused the error? It happens to me sometimes... Thank you

[Clyde Schechter]

I certainly sympathize. It does happen to me, I'm sure it happens to everyone, and it's no fun at all.

I do not work for StataCorp, so I don't really know why they haven't implemented this. But I can hazard a guess.

I think it would be very difficult to implement. Stata code is interpreted. When you have blocks of code that get iterated, the entire block is read in and interpreted as a unit. The interpretation process most likely involves translating from the code we write into some simpler, more primitive kind of pseudo-code that then gets run by a virtual machine of some type. (This is how Java works, for example.) The error, however, is detected while the virtual machine is running. The virtual machine does not have access to the original Stata code that was written--it just sees its own pseudo-code. So it doesn't know how to tell us what our code looked like at that point. This same problem does not arise outside of blocks of code because there's only one line of code, which was displayed in the Results window even before the parser, let alone the virtual machine, got a hold of it. It is, in effect, a happy coincidence that the error message appears immediately after the command that threw the error.

Now, it is possible to work around this by instead of parsing and running the entire block, just interpreting one line at a time. The problem with that is that every line in the loop would have to get re-translated on each iteration of the loop--and since the code isn't changing this is enormous redundancy. It would slow execution speed to a crawl.

[Esteban Jara]

Excelente explicación, muchas gracias!