How to get the most out of the new Google Apps Script debugger & logging
Building and maintaining code can be hard. There are multiple phases in the livecycle of the code, each phase with its own challenges. Being able to easily retrieve information about the execution of your code in each phase is key. This is where the new Google Apps Script IDE debugging and logging features can help. In this article I will show you what you can do with the new debugging and logging features.
A simple Google Apps Script is used to walk through the powerful features of the debugger and logging. In the final part of the article we will take it a step further and implement the Google Cloud logging module. After reading this article you will have a good understanding of the options to debug and monitor your Apps Script applications.
The debugger
The debugger enables you to walk through the code step by step. When in debug code the function will run until a debugger statement, or a breakpoint is encountered. The debugger statement only has an effect when the code is run in debug mode.
I will use the following code to showcase the features of the debugger:
The code can be started by clicking on the debug button. Make sure that you select the correct function to debug.
In the screenshot below you can see the debugger in action. The function started and stopped at the “debugger” keyword on line 6.
To resume the execution of the code I clicked on the play button. This action will resume the function until it encounters a debugger statement or a breakpoint. In this case it encountered a breakpoint on line 14 and stopped. The three buttons next to the play button provide finer grained control over the debugger. When you hover over the buttons they will show some information on what they do.
On line 14 I placed a breakpoint. Breakpoints can be placed by clicking left of the line number where you would like the debugger to stop. Notice the variables section and the localNumber variable pointed out by the green arrow. The variable section will show you the values of all the variables.
The execution log pointed out by the yellow arrow contains the log information. This information will also be shown if the debugger is inactive.
The call stack
If you play a bit with the example code you will see that the debugger is straightforward and easy. I designed the example code to highlight an useful feature in the new debugger, the call stack.
The example code defines a global variable, and loops over two arrays. The outer loop walks through an array of four numbers and the inner loop walk through an array of 2 characters.
In the screenshot below I placed a breakpoint on row 19 and ran the debugger:
In the call stack I selected the first line and the localCharacter variable shows as “A”. However when you select line 16 as shown in the next screenshot it becomes interesting.
Now the local variable is localNumber and has the value 1. This is the value of localNumber when the inner loop over the two characters started. This way you can see all the variables that are relevant to the current state of the code.
Logging
Logging is the tool that will enable you to gather information about the code while it is running. Consider the following code:
Nothing special here, but when we run it we see the following:
We now have two extra log levels, Error and Warning. These levels are very useful to distinguish between the severity of the message.
Stackdriver logging
Logging can be taken to the next level if you use the stackdriver logging. This is just a teaser, using stackdriver does require a deeper understanding of the Google Cloud Platform and the project that is linked to the script. I will only show some high level information here.
The screenshot below shows the log browser on the Google Cloud Platform:
Besides a great way to explore the logs it is also possible to direct the logs of multiple scripts to a single location. Another great feature are the alerts, based on metrics you can trigger an email or other alerts to notify a stakeholder when something is wrong with the application.
Timing
Last but not least, timing. Once you debugged the code, and logging provides runtime information you might need performance metrics.
In the following code we can measure the time a section of code takes to execute.
Simple, yet powerful. This piece of code took 52 milliseconds to run.
Wrapping up
In this article I have shown how to use the debugger, log information and measure time. These features will provide you with information about the inner workings of your code. The best way to do this is, is to play with the examples and implement the logging statements.
Stackdriver logging is useful in a professional environment where reliability becomes more important. It takes a bit more time to set up, however it is worth it when you get an email with the error before you get a phone call from the user of your script.
