Debugging Code In The Apps Script Editor

This article will be useful to those who need to change or modify their Apps Script code (including the code posted on this site) to their immediate needs.

And the first question:

What To Do If The Modified Script Stops Working?

Of course, in order for the code to work again, it needs to be debugged.

And first of all, we need to find a place after which problems begin and the code behaves in a completely different way from what is expected of it.

There may be several strategies here. The most reliable of them (but not the fastest) is to check the entire code step by step, starting from the very beginning.

To do this, in the editor window, you must:

• select the function to be debugged (in the figure, this is the tmp() function);
• set breakpoint - in the figure it is a purple dot to the left of the 32nd line number;
• and click the Debug button (in the header above the code block, between the Run button and the name of the debug function).

In this figure, the program stopped just at the breakpoint on the 32nd line.

In the same figure, you can see that in the right block under the heading Debugger there are four buttons:

1. Resume button (triangle) - pressing this button will continue the program execution until the next breakpoint (or until the end of the program if there are no more breakpoints).
2. Button Step Over (point with an arcuate arrow) - pressing ensures the execution of the current line and the transition to the next line.
3. Button Step In (arrow pointing down to the point) - if the current line is normal, then the current line will be executed and the transition to the next one will be performed (as with the Step Over command) . But if the current line contains a function, the transition will be made inside this function, that is, to the first line of code inside this function. (In the example in the figure, this is line 36, which contains the function fillColumn. Pressing Step In on line 36 will “take” the debugger inside this function)
4. Button Step Out (up arrow from the dot) - the current function will be completed and the next breakpoint will be the first line after the current function call line (in our example, this is line 37).

Below the control buttons of the Debugger block is the Variables block, which shows the current value of the variables at each program breakpoint.

In addition, we can print the desired values to the console using the command:

console.log(variable)

These data are displayed on the images in the lower part in the Execution log block.

How To Debug Function Code With Arguments?

If we want to test the operation of a function that has arguments (for example, the function fillColumn(row, col, mask)), then the best solution is to first create a helper function tmp(), where

• First, the values of all arguments of the fillColumn function will be set - the variables row, col, and mask;
• And then the fillColumn(row, col, mask).
function itself will be called

Then, the launch of this very auxiliary function tmp() for debugging, in fact, will be the launch of the fillColumn function itself with arguments.

In fact, in the figure above, the tmp() function plays a similar auxiliary role for the fillColumn(row, col, mask) function.

How To Debug The Code Inside The onEdit(e) Function?

The onEdit(e) system function is used to intercept data changes/entry on Google spreadsheet and does not respond to the standard breakpoint processing by the debugger. Therefore, we will not be able to debug it in the usual way.

There are at least two solutions:

1. Create a helper function to first transfer all the logic of the onEdit(e) function into it and debug it there using predefined input data. And after debugging, transfer the finished and debugged code back.
2. Debug onEdit(e) what is called “in place”, but use windows called by the Browser class as breakpoints:

Browser.msgBox(variable);

For the convenience of debugging the second scenario, you can add the values of any variables as arguments to variable.