STEPGO number
Tells the application to start executing until it reaches one of the breakpoints, an error, or the depth equals the number given above. The application responds:
GO COMPLETE
GO COMPLETE WITH ERROR
GO COMPLETE WITH TRAPPED ERROR
GO STOPPED
depending on if the go stopped due to an error being received or because of reaching a breakpoint. In the case of an error, an untrapped error indicates that the error message is going to printed to the user and so should be printed to the debugger's user as well. See GET below on how to get the error's value.
Use the depth to implement step over and step out. A normal go should have depth as 0, meaning it only stops when it reaches depth 0 (i.e. the script ends). Use the current depth, retrieved by REPORT, to step over. Use the current depth minus one to step out.
Stopping with TRAPPED ERROR means that the exception is going to be handled, perhaps by a try/catch block. However, often debuggers will have the option to break on any error. If the debugger is not using this option, it will want to ignore trapped error returns. Use REPORT to find the current depth and see if the action (step out/step over) is complete. If it is not complete, or in the case of a generic run, just call GO again. This same mechanism can be used to trap some errors, such as range errors, but not others. Most debuggers have all kinds of options on exactly which errors should stop execution and which should not.
The final possible response, GO STOPPED, happens if the debugger stops the go command prematurely. It does this by sending a STOP command to the application while the GO is still processing. If this command is received at any other time, it is ignored completely with no response. This is because the debugger may send the command but the application finish its GO before receiving it. The stop will then be the next command the application finds. If it made some kind of response to it, the debugger sends command, application responds format we be broken.