The following code works perfectly if run normally
function initialPopulation()
{
var group = ContactsApp.getContactGroup('clients');
var myContacts = ContactsApp.getContactsByGroup(group);
for (var i=0;i<myContacts.length;i++)
{
var row = i+1;
var getPrimaryEmail = myContacts[i].getPrimaryEmail();
ss = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
ss.getRange("A"+row).setValue(getPrimaryEmail);
var temp=0;
}
}
If I debug the code, without any stops, it also runs perfectly without issues.
However, if I try to debug the code, with a stop on the line "temp=0", then continue to debug, it will always crash:
We're sorry, a server error occurred. Please wait a bit and try again.
(line 10, file "Code")
Line 10 is:
var getPrimaryEmail = myContacts[i].getPrimaryEmail();
Any ideas what could be happening?
This is driving me crazy because I cannot debug more complex code.
I can confirm this, even in an older script that I am fairly certain I have previously single-stepped through. What a show-stopper.
Further, you can reproduce the same error with .contact.getEmails(), so my bet is that a bug has been introduced. No sign of it on the issue tracker, unless you count Issue 5502.
I recommend raising a new issue. (Done: Issue 5515.)
In the mean time, you can work around the problem by NOT single stepping over methods like this one that the debugger can't unspool. That means that you cannot have any breakpoints BEFORE the fatal line, as it will die on continuation.
Related
I used to be able to put a break point in a javascript function and change variable values to debug. This worked until recently (within a week or two).
Here's an example:
function test(params) {
var result = params.num * 2;
// if I put a break point here and change result = undefined,
// it doesn't work
return result;
}
// I should get 6, but when debugging and changing result to undefined,
// I should get undefined in my output, used to, not anymore
var x = test({ num: 3 });
console.log(x);
I'm using OSX Yosemite Chrome v. 49.0.2623.110 (64-bit)
It is up to date and I just restarted Chrome.
I do this all the time, but something happened recently and I can't anymore. Any help would be greatly appreciated.
Thanks
It looks like this was documented behavior for a while. Just yesterday a change was made to the code that says it will restore the ability to change variables. It is very disappointing that they allowed it to break for any length of time.
https://bugs.chromium.org/p/chromium/issues/detail?id=569811&q=debugger%20change%20variable&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified
function fc () {
var x = 11
var y = x.toString()
return y
}
I execute this in a script file bound to a spreadsheet,
and get a the following error message:
We're sorry, a server error occurred. Please wait a bit and try again.
If I execute that same function in another script file,
it works as expected, without error message.
The same happens with "simply" changing x to string:
var x = "11"
There may be an "easy" explanation but while you are at it, it feels
like living a Gary Larson-Cartoon ...
I just ran that script with no problems. I think I've had that error msg before for something that didn't have anything to do with the server. It's impossible to capture every possible error perfectly. Once in a while you get a misleading error. I'm not saying that definitely is the situation, but just keep it in mind.
You have to go through the debugging process. I've had to comment out large sections of code many times and go back to the beginning to trace errors. Sometimes that's the only way. Start commenting out code until you get something to run without an error, then add lines back in until another failure.
While using MailCore2, I started getting an error in MCHTMLCleaner.cc and method HTMLCleaner::cleanHTML. The specific line that is throwing the error is:
rc = tidySetErrorBuffer(tdoc, &errbuf);
and the error being printed is:
'Assertion failed: (option_defs[ optId ].type == TidyInteger), function SetOptionInt, file ../../src/config.c, line 381'
In config.c on line 381 is:
Bool status = ( optId < N_TIDY_OPTIONS );
Occasionally, this will crash the app, which seems contrary to the entire idea of a try/catch block that would make the most sense here.
More often than not, this code/file will not stop the app and instead just print out an error.
What is causing this to crash? Has anyone else experienced this? IS the HTML actually being cleaned or is nothing being returned for you?
Here is a link to the specific file in question on GitHub.
I have a work flow...
ondblClickRow: function (id) {
debugger;
var rowData = $("#list").getRowData(id);
...
}
This function call is throwing an exception whereas it previously worked. Actually stepping into the mini-fied code I can see that there is an array out of bounds exception of sorts. There are only seven columns and it appears to be calling an eighth (zero indexed-I have columns from 0-6, and it appears to be asking for a seventh). Not sure what is going on in that particular exception. I am still researching, but this was working fine and I did not change anything related to this in weeks. AM I missing something here?
This is kind of a hack work around, but I simply just got the cell values that I needed based on the id and the column names that I needed so I could circumvent any issue that might be occuring... Even though I am not sure what happened. I am still very curious as to why this occured. More research will need to be done for me to be more comfortable with this solution...
var FName = $('#list').getCell(id, 'First_Name');
I'm getting some warning signs in FDT in a couple of lines of code that access values in the app descriptor, like this:
var appDescriptor:XML = NativeApplication.nativeApplication.applicationDescriptor;
var ns:Namespace = appDescriptor.namespace();
var appId:String = appDescriptor.ns::id[0];
var appVersion:String = appDescriptor.ns::versionNumber[0];
Those lines work fine, but FDT underlines "id" and "versionNumber", and issues the warning "Could not resolve variable (may be an XML element name)".
Is there a way to get rid of that warning?
Sort of, you can use this snippet:
/*FDT_IGNORE*/
// your code
/*FDT_IGNORE*/
to have FDT ignore the code therein. Another option is to try these settings. Otherwise try different parser / error settings to see what happens.
Preferences http://dl.dropbox.com/u/154189/web/never/Preferences.png