Here is some reference material:http://www.w3schools.com/jsref/jsref_obj_string.asp
The main troubleshooting tool, that most people use is:
There are two parts to that statement:
Whatever you put inside the parenthesis will be printed to the “Logs”.
Logger.log(‘My function ran!!!! I don’t believe it!’);
You can also put variables inside the parenthesis:
var ‘myVariableName = ‘this is a test’;
Logger.log(‘myVariableName: ‘ + ‘myVariableName);
To view the print out, click the VIEW menu, and choose: LOGShttps://developers.google.com/apps-script/troubleshooting
If you have a relatively good idea of what part of the code an error is coming from, then go directly to that area of code, and scrutinize it. But, it often happens that many changes get made to lots of lines of code, in lots of files before running a test, and in that situation, you don’t know where the error is coming from. Debugging efficiently is a logical process of elimination. Think, “Sherlock Holmes”. That’s what you need to be, a detective. Random, trial and error will only get you so far. There are situations where the number of different things you could try is a number so large, that you could spend your entire life, just making random changes to the code, hoping it will work, and you’d need to live to be 10,000 years old before you could try every variation. So, if you need to find the error in a certain amount of time, random, desperate attempts to fix the problem will fail you sooner or later.
So, the “process of elimination” is the common theme in the debugging strategies that I advise you to use. But, with that being said, the very first thing I always try is the opposite of a logical process of elimination. I start with intuition and memory. “It’s probably in this file, in this function, and I remember just making a change that could have given me this error”. That’s the fastest route, IF IT WORKS. If it doesn’t work, then you switch modes, and go through the logical process of elimination. Where people get “stuck”, is trying to switch from desperation mode, to going through the process. Going “through the process” is tedious, boring and could be time consuming. It’s not a very appealing prospect.
Start at the beginning - For relatively small sections of code, just start at the beginning and trace the code through.
Delete half, then delete half again, and repeat. For things like uncaught HTML errors. I comment out, or delete half the functions in the script tag, or half the HTML, or CSS and try it, and see if there is an error. Using this technique, you can eliminate 50% of the content that is not producing the error very quickly. So, that cuts the amount of code you need to review in half, in a very short time. Then you eliminate 50% of the 50% that’s causing the error. So, in two steps, you’ve narrowed the area to look in by 75%.
Intentionally cause an error that stops the code. If you can determine that the code is working up to a very specific point, then the next line of code is probably where the error is. So, I’ll intentionally add a non-existent function, that causes an error, in order to stop the code: Like xyz(); If there is no “xyz()” function, then an error will occur, an error will display, and the code will halt. If no other error happens before the forced error, then the code is working up to that point. So, I very quickly know, up to what point the code is good.
Try/catch prevents the Execution Transcript from handling the error. The Execution Transcript tells the line of the error, and gives an error message. For "production" purposes, you must use Try/Catch to "Fail Gracefully", but for development, I often prefer to just look in the Execution Transcript. But, this may be one of those cases where there is no right answer, and it's personal preference.
In very specific situations, I use the debugger to step through lines of code, one by one. I rarely use the debugger, but in certain situations it is a critical tool and extremely helpful. So, what are the situations that warrant using the debugger?
You are learning what a new method or property does, and you aren’t really sure what the method or property returns, or how it works. When you see the results happen right in front of your eyes, then it helps to understand.
The program flow is complicated enough, so that you are having difficulty imagining how the code is branching, or checking conditions, and there are lots of possible outcomes that are difficult to evaluate all at once. For example, when you see how three “OR” conditions are being evaluated in the same IF statement, and it’s not what you ever believed would have happened, it’s confirmation of what is actually happening. There is a difference between expected and actual results.
Debugging Code triggered from a Google Form submission:
The Google Form is obviously in a different tab than the code editor. When you submit the Form, you can VIEW the LOGS, and see the print out in the code editor, even though the code was triggered from a different browser tab.
You can halt the code anywhere you want to with a return statement. Halting the code at a specific point can help you know up to what point the code is doing what. If you halt the code with a "return;" statement, no error will be produced. The danger in debugging your code with a "return;" statement, is that if you forget to remove it, there is no error telling you that something is wrong. If there is a red error message telling you that the code halted on a specific line, then you know exactly where to go. To intentionally create an error, you can call a non-existent function:
You'll get an error message that it can't be found.
You can not add a breakpoint to code that has been triggered to run outside of the code editor.