Take this code, we have a promise that calls a function that will fail, and it should pass the error onward to the catch method of the promise.
It works just fine when ran from the terminal.
However when ran through vscode it explodes at (1).
function failingFunc() {
let undef = undefined;
return undef.nope();
}
let promise = new Promise((resolve, reject) => {
resolve(failingFunc()); // (1) Explodes when run from vscode
});
promise.then(v => {}).catch((e: Error) => {
console.log(e.message); // (2) Prints when run from the terminal
});
Why is this?
vscode about page:
Version 1.14.2
Commit cb82feb
Date 2017-07-19T23:26:08.116Z
Shell 1.6.6
Renderer 56.0.2924.87
Node 7.4.0
Solution
As @T.J.Crowder pointed out in the comments:
This only happens when an exception is thrown causing a rejection before a handler is attached. E.g., this wouldn't cause it, because when the exception is converted to rejection, there's already a rejection handler attached:
new Promise((resolve, reject) => setTimeout(() => {
try {
throw new Error();
} catch (e) {
reject(e);
}
}, 0)).catch(error => console.log("Error:", error));
Turns out this is a known "bug" when using vscode to debug Nodejs.
As its explained in this issue (over at the vscode git repository) this happens because Nodejs send a break-event with an undefined
exception when ever it encounters a reject
callback. When vscode's debugger sees this break-event it does what its supposed to do with unknown exceptions, it pauses the execution and then throws the exception.
Further more in this issue (over at the vscode-node-debug2 repository) @roblourens says that:
If a promise is rejected before an error handler is attached, the debugger will break, even if only "uncaught exceptions" is checked. If it's rejected after the error handler is attached, it works as expected.
And really the problem is the way the promise doesn't know whether its rejection will be handled or not.
You can still use vscode for developing Promise based systems, however you will need to turn off all error handling in vscode, as seen below make sure neither of the options are ticked.
NOTE: Since this is far from an optimal solution, it is likely to get changed and or improved in the future.
(I've commented on the vscode issue and will update this post if I learn anything useful)
Edit1:
I've found that another workaround is to define a keybinding in vscode to run the command workbench.action.debug.run
. This will run the current selected debug option without attaching the debugger to it. This means that you can keep the debugger on your normal settings, while running the code using the new key command when you need to work with rejected promises.
/* keybindings.json */
[
{
"key": "ctrl+shift+b",
"command": "workbench.action.debug.start"
/* Attaches debugger */
},
{
"key": "ctrl+b",
"command": "workbench.action.debug.run"
/* Runs without debugger */
}
]
Edit2:
As @T.J.Crowder pointed out in the comments:
This only happens when an exception is thrown causing a rejection before a handler is attached. E.g., this wouldn't cause it, because when the exception is converted to rejection, there's already a rejection handler attached:
new Promise((resolve, reject) => setTimeout(() => {
try {
throw new Error();
} catch (e) {
reject(e);
}
}, 0)).catch(error => console.log("Error:", error));
And of course he was right. The code below does work in vscode with the debugger attached.
function failingFunc() {
let undef = undefined;
return undef.nope();
}
let promise = new Promise((resolve, reject) => {
setTimeout(() => {
try {
resolve(failingFunc())
} catch (e) {
reject(e);
}
}, 0);
});
promise.then(v => {}).catch((e: Error) => {
console.log(e.message); // Cannot read property 'nope' of undefined
});