vscode debugger stops on reject()

[a8775]

Node 4.5.103.35, vscode: 0.10.6

'use strict';

class MyClass {
    f(f: boolean): Promise<void> {
        return new Promise<void>((resolve: () => void, reject: () => void) => {
                if(f===true) reject();
                else resolve();
            });
    }
}

var c = new MyClass();
c.f(true).then(()=> console.log('OK')).catch(()=>console.log('ERR'));

Debuger stops on reject(), with message "Paused on exception" without exception details, no breakpoints are set except "uncaught exception".

[weinand]

I've verified that node.js sends indeed a break event with an 'undefined' exception for the reject(), so the behavior is correct.
I will investigate whether VS Code could try to swallow the event and continue.

[ghost]

Any advance in this?

[pflannery]

I'm having the same issue in vscode v1.6.
vscode debugger always stops regardless of the promise rejection being handled correctly

if I run the below code using the cmd line $ node debug app.js I'm not given a break event when a rejected promise is handled by the code.
If I comment out the catch code I then get a UnhandledPromiseRejectionWarning exception

// app.js
function test(shouldReject) {
  return new Promise((resolve, reject) => {
    shouldReject ? reject("rejected") : resolve("resolved")
  })
}

let shouldReject = true
test(shouldReject)
  .then(result => console.log(result))
  .catch(err => console.log(err)); // commenting this line will cause nodejs to throw UnhandledPromiseRejectionWarning

Would be nice if vscode debugger replicated the same behaviour as node debug and not break on a handled promise rejection when "uncaught exceptions" is ticked.

[weinand]

@pflannery please try to use our new experimental node debugger by setting the debug type to "node2" (and you will have to use a node.js version >= 6.3).

[weinand]

@roblourens when trying the snippet from above with node2, I stop in line 4 on a "debugger statement" (whereas node-debug stops on an exception).

[weinand]

VS Code 1.7 tries to identify exceptions that result from rejects() and skips them if the 'All Exceptions' checkbox is not set.

/cc @roblourens

[roblourens]

Hm, I see the problem, but I'd rather keep Chrome DevTools' behavior here for node2. I think it's something that would have to be addressed on the runtime side.

With this change, you could have a false positive and skip a line just because it happens to have the word 'reject' on it. You could also have the callback named something other than 'reject'. And at that point, you don't know whether the rejection is handled, so you could be skipping an unhandled promise rejection.

[weinand]

@roblourens fair points... I will disable this feature for now.
However, I noticed that node-debug2 reports the information for rejected promises as "debugger statement". This sounds wrong. Is this really intended? (see screenshot above).
In addition in the CDP a "paused" event has a reason "promiseRejection" so node-debug2 could easily introduce a new exception filter for promise rejections that would not suffer from the 'false positive' problem.

@a8775 @DryRuskFromLS @pflannery
node's v8 debugger protocol does not return any information to distinguish 'promise reject' exceptions from other exceptions. So I cannot offer a reliable mechanism to automatically skip rejected promises but still stop on other uncaught exceptions.
Node-debug2 night be able to add this feature in a robust way.

I will leave this feature request closed since there is already a way to prevent the debugger from stopping on reject() by means of the 'uncaught Exceptions' checkbox (and I cannot do more with the limitations of the now obsolete v8 debugger protocol).

[roblourens]

Good points @weinand, I filed an issue to look at that in node-debug2

[linvi]

Hello there. I am still facing this issue. My VSCode is 1.7.2 and if I have Uncaught Exceptions I received reject as being an exception.

If I unselect it I no longer receive it.

But obviously I do not want reject to break but I do want to receive all Uncaught Exceptions.

Am I doing some thing wrong?

Here is a screenshot of vscode with a break happening on a reject without having a specified breakpoint for it.

[weinand]

@linvi what you are seeing is the native node.js behavior. Please read my comment #1746 (comment).

[pflannery]

@weinand does that mean node is overriding its own native behaviour when running $ node debug from a terminal?

[weinand]

node debug is node's own debug UI that has access to more runtime internals than VS Code has through the v8 debugger protocol.

[kaefert]

I think I'm observing the same issue here. VS Code stops here on every page load. When I step over the marked line the fetchPromise has the status "rejected".

I'm running VS Code 1.8.0, Commit 3874693, Shell 1.4.6, Renderer 53.0.2785.143, Node 6.5.0

[vwzhang]

I am having this problem too with 1.9.1, zonejs 0.7.6. I tried to all the combination of put empty string into the fetch and/or toggle chrome pause on caught exception with no luck. I don't understand such a simple thing cannot be resolved. Either fixing zonejs.fetch or ignore it from vscode. Is this because both are free open source stuff?

[ghost]

I want to break on rejected promises but not all exceptions.

I am trying to debug a gulp build that is failing with a (nondescript) promise rejection. If I set the debugger to break on Uncaught Exceptions, it never breaks. If I set the debugger to break on All Exceptions, it breaks every time the build tries to stat a file (1000s of times).

There appears to be no way to break on promise rejections.

[electrotype]

I have this issue using [email protected]: when I launch a debug session, VSCode breaks because of this line.

My question : is there a project setting I can use to disable the Breakpoints - Uncaught Exception checkbox in VSCode by default? This break is so annoying.

I tried using skipFiles in my launch config :

"skipFiles": [
    "${workspaceFolder}/node_modules/**/*.js"
 ]

But VSCode still breaks when Breakpoints - Uncaught Exception is checked.

Is there a way/workaround/anything other than manually uncheck Breakpoints - Uncaught Exception to prevent VSCode to break on this line?

[Olian04]

@electrotype take a look at this SO question

[electrotype]

Thanks @Olian04 . Sadly, I don't want to disable debugging on this project.... I need to start it in debug mode.

I really wish there was a project setting to disable Breakpoints - Uncaught Exception by default!

[roblourens]

@electrotype If you uncheck "Uncaught Exceptions", it should stay unchecked in that workspace until you check it again.

skipFiles unfortunately won't work here because it doesn't apply to uncaught exceptions, and Node calls the rejected promise an "uncaught exception" here even though it isn't really. Related to this bug I filed on chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=755728&q=rejected%20promise%20&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

This is the same behavior as "blackbox script" in chrome devtools.

[electrotype]

Thanks for the info @roblourens . But we are a big team : people checkout the project and run it as adviced... That "error" doesn't look good at all! I now have to ask them to uncheck Breakpoints - Uncaught Exception by themselves, in the documentation?

[roblourens]

@weinand @isidorn - Chrome and FF devtools don't break on any exceptions by default. I think I should change the default for "Uncaught Exceptions" to 'false'. Thoughts?

[roblourens]

Another possibility would be continuing automatically from files in skipFiles (like smartStep) so we can skip uncaught exceptions which aren't really, since Chrome still pauses there even in blackboxed scripts.

[weinand]

Let's investigate this in December.

[roblourens]

I changed the "uncaught exceptions" default to false for now at least.

[jeffmcaffer]

I have this problem as well using Node's util.promisify (in v 8.9.4). Using the sample below and running from vscode, you would expect "just cause" to pop out on the console. Instead, the debugger stops with "Exception has occurred: Error" (see screenshot below). Continuing the execution works just fine but it means you have to run with Uncaught Exceptions turned off which of course, is a challenge in scenarios where you are trying to deal with real uncaught exceptions.

const { promisify } = require('util')

function bar(callback) {
  callback(new Error('just cause'))
}

async function foo() {
  try {
    await promisify(bar)()
  } catch (error) {
    console.log(error.message)
  }
}

foo()

[roblourens]

Unfortunately I don't have any better solution here. The 'undefined' mentioned in the OP is technically correct for that case. The issue of node sending the wrong pause reason has been fixed, so now the call stack label is correct. My investigation in microsoft/vscode-node-debug2#46 is another explanation of what's happening.

My suggestion of

Another possibility would be continuing automatically from files in skipFiles (like smartStep) so we can skip uncaught exceptions which aren't really, since Chrome still pauses there even in blackboxed scripts.

I would consider out of scope for now.

I think we will have to wait for better support from the runtime regarding "break on exception" for async-handled exceptions.