1

This issue has been reported to Google: https://issuetracker.google.com/issues/152948662

A short description of the issue

In the Rhino runtime, the script debugger (script.google.com) would break on any line containing an error (handled or not) if the uses pressed the "debug" button on the toolbar. (It won't break if the user presses the "run" button). The watch windows would be activated and the user can inspect the variables in force at the time of the error.

In the V8 runtime, the script debugger will not break on any error under any circumstances. This is very unhandy for debugging.

A small code sample that reliably reproduces the issue

The sample should run as-is or with minimal setup, without external dependencies

function testError() {
  var a = {
    title: function() { console.log('hello world') }
  }
  a.titel(); // rhino would break here because of this (unintentional) typo; V8 will not.
}

What steps will reproduce the problem?

  1. Create a new project

  2. Insert the code into Code.gs

  3. Debug the code

What is the expected output? What do you see instead? If you see error messages, please provide them.

Expected: debugger breaks on line with asdfgh()

Actual: debugger exits debugging

Messages: the debugger (very) briefly shows the error as a toast and logs the unhandled error under logs and executions.

Please provide any additional information below:

Side note: not important for this bug. Just extra info FYI. Don't let this distract you or trip you up

If this bug can be fixed, I can use my homegrown function that effectively allows me to have "breakpoints" anywhere in the code, thus getting around another bug GAS debugger has (breakpoints only hit on current file):

Break(condition, watch) {
  try {
    if(!App.Objects.isUndefined(condition) && !condition)
      return false;
    // you have to step over until you leave Break(). Run doesn't work from here.
    thisFuncDoesntExist();

  } catch (e) {
    return true;
  }
}

Under Rhino, I could put a call to this anywhere and the debugger would stop for me there. But this is just a side note.

Rubén
  • 34,714
  • 9
  • 70
  • 166
toddmo
  • 20,682
  • 14
  • 97
  • 107

1 Answers1

4

You should use the JS statement debugger. It's the standard way to insert breakpoints for debugging in Javascript. In GAS use the debug button to run your function and the execution will stop at every debugger; statement.

For example you will be able to update your testError function like this:

function testError() {
  var a = 'hello world';
  debugger;
}

Pausing execution on unhandled exception

V8 GAS Runtime debugger won't pause on exceptions. You will have to explicitly insert breakpoints in order to pause the running process. You could wrap your function in a try-catch in order to trigger the debugger on unhandled exceptions.

function myFunction() {
    try {
        // myFunction body...
    } catch(e) {
        debugger;
    }
}

Rolling back to Rhino:

However, if you really need this feature you can switch back to the old runtime.

In the manifest file change this parameter: "runtimeVersion": "DEPRECATED_ES5"

This comes at a price though: you won't be able to use modern JavaScript syntax.

Reference:

V8 Runtime

Alessandro
  • 2,848
  • 1
  • 8
  • 16
  • Thank you, this allows me to make my `Break` function to work again. Upvoted. However, how do I get V8 to automatically break on all unhandled errors like Rhino did? – toddmo Apr 02 '20 at 17:27
  • V8 doesn't pause on exceptions. It does log them of course. I edited my answer with a workaround. – Alessandro Apr 03 '20 at 11:07
  • Thanks for the edit. I'm unclear whether this behavior is by design; the reference doesn't say. I'm hoping either it's a bug, and I get some useful feedback from the dev team, or someone can come up with a clever way to trick it into doing what we want. (for example, the V8 engine itself has tons of configurable options and maybe there's an undocumented way to set them in the `appscript.json` or somewhere else). If I don't get anything along those lines in a week I'll mark yours b/c at that point it would probably represent the best we can do in the current situation. Thanks! – toddmo Apr 04 '20 at 17:52
  • What about wrapping your function in a try catch and triggering the debugger on exceptions? – Alessandro Apr 06 '20 at 12:35
  • That's a good idea to catch errors when they happen, and I have that code working, but it's currently commented out because `try / catch` doesn't stop on the location of the error. So I have to look at the output and then use `debugger;` where the error occurred to further investigate what happened. – toddmo Apr 07 '20 at 16:48
  • I see, there is no such feature in Google Apps Script debugger. You can always use the `STABLE` version of the runtime and file a feature request for V8 in the meantime: https://developers.google.com/apps-script/support#missing_features – Alessandro Apr 08 '20 at 09:19
  • Thanks again for all the effort. No one else stepped forward so I'm marking this as the answer. I did file an issue about this bug. If they fix it, we will be good! – toddmo Apr 08 '20 at 15:58
  • For my current program I greatly prefer this behavior. I am iterating through a user's e-mail groups (old runtime) and if one of them is "private" an error is generated. I'm trapping the error with Try/Catch but in debug mode my code stops on the error every single time. Kind of annoying. – John Cutter May 30 '20 at 04:31