Develop Reference

Any way to cause a promise to be rejected if it has an uncaught error?

It's easy to forget to use try/catch in an async function or otherwise fail to catch all possible errors when working with promises. This can cause an endless "await" is the Promise is never resolved nor rejected.
Is there any way (such as via a proxy or altering the promise constructor) to cause an async function or other promises to be rejected if there is an uncaught error? The following shows a generalized case. I'm looking for some way to get past the "await" (as in "p" should be rejected when the error is thrown) without fixing "badPromise".
async function badPromise() {
const p = new Promise((res) => {
delayTimer = setTimeout(() => {
console.log('running timeout code...');
if (1 > 0) throw new Error('This is NOT caught!'); // prevents the promise from ever resolving, but may log an error message to the console
res();
}, 1000);
});
return p;
}
(async () => {
try {
console.log('start async');
await badPromise();
console.log('Made it to the end'); // never get here
} catch (e) {
console.error('Caught the problem...', e); // never get here
}
})();```

Promises already reject in the case of an uncaught synchronous error:
in a Promise constructor, for synchronous (thrown) errors
If an error is thrown in the executor, the promise is rejected.
in onFulfilled and onRejected functions, such as in then and catch
If a handler function: [...] throws an error, the promise returned by then gets rejected with the thrown error as its value.
in async functions
Return Value: A Promise which will be resolved with the value returned by the async function, or rejected with an exception thrown from, or uncaught within, the async function.
Your problem here isn't that Promise doesn't handle uncaught errors, it's fundamentally because your error is asynchronous: As far as the Promise is concerned, its executor function is a successful little function that calls setTimeout. By the time your setTimeout handler runs and fails, it does so with its own stack that is unrelated to the Promise object or its function; nothing related to badPromise or p exists within your setTimeout handler other than the res reference the handler includes via closure. As in the question "Handle error from setTimeout", the techniques for catching errors in setTimeout handlers all involved editing or wrapping the handler, and per the HTML spec for timers step 9.2 there is no opportunity to catch or interject an error case for the invocation of the function passed into setTimeout.
Other than editing badPromise, there's almost nothing you can do.
Alternatives:
Modify/overwrite both the Promise constructor and the setTimeout method in sequence, wrapping the Promise constructor's method to save the resolve/reject parameters and then wrapping the global setTimeout method so to wrap the setTimeout handler with the try/catch that invokes the newly-saved reject parameter. Due to the fragility of changing both global services, I strongly advise against any solutions like this.
Create a wrapper higher-order function (i.e. function that returns a function) that accepts a rejection callback and wraps the setTimeout call. This is technically an edit to badPromise, but it does encapsulate what's changing. It'd look something like this:
function rejectOnError(rej, func) {
return (...args) => {
try {
return func(...args);
} catch (e) {
rej(e);
}
};
}
async function badPromise() {
const p = new Promise((res, rej) => { // save reject
delayTimer = setTimeout(rejectOnError(rej, () => { // to use here
console.log('running timeout code...');
if (1 > 0) throw new Error('Now this is caught');
res();
}), 1000);
});
return p;
}
badPromise().catch(x => console.error(`outer: ${x}`));
console.log('bad promise initiated');

The underlying issue is that timer callbacks run as top level code and the only way to detect errors in them is to listen for global error events. Here's an example of using a global handler to detect such errors, but it has issues which I'll discuss below the code:
"use strict";
let delayTimer; // declare variable
async function badPromise() {
const p = new Promise((res) => {
let delayTimer = setTimeout(() => { // declare variable!!!
console.log('running timeout code...');
if (1 > 0) throw new Error('This is NOT caught!'); // prevents the promise from ever resolving, but may log an error message to the console
res();
}, 1000);
});
return p;
}
(async () => {
let onerror;
let errorArgs = null;
let pError = new Promise( (res, rej)=> {
onerror = (...args) => rej( args); // error handler rejects pError
window.addEventListener("error", onerror);
})
.catch( args => errorArgs = args); // Catch handler resolves with error args
// race between badPromise and global error
await Promise.race( [badPromise(), pError] );
window.removeEventListener("error", onerror); // remove global error handler
console.log("Made it here");
if( errorArgs) {
console.log(" but a global error occurred, arguments array: ", errorArgs);
}
})();
Issues
The code was written without caring what is passed to an global error handler added using addEventListener - you may get different arguments if you use window.onerror = errorHandler.
The promise race can be won by any error event that bubbles up to window in the example. It need not have been generated in the badPromise() call.
If multiple calls to badPromise are active concurrently, trapping global errors won't tell you which badPromise call errored.
Hence badPromise really is bad and needs to be handled with kid gloves. If you seriously cannot fix it you may need to ensure that you only ever have one call to it outstanding, and you are doing nothing else that might generate a global error at the same time. Whether this is possible in your case is not something I can comment on.
Alternative
A more generic alternative may be to start a timer before calling badPromise and use it to time out the pending state of the returned promise;
let timer;
let timeAllowed = 5000;
let timedOut = false;
let timeout = new Promise( res => timer = setTimeout(res, timeAllowed))
.then( timedOut = true);
await Promise.race( [badPromise(), timeout])
clearTimer( timer);
console.log( "timed out: %s", timedOut);

There may be a way to do this, but in your case I think you really want to use the reject function inside your Promise instead of throw. That's really what reject is for.
async function badPromise() {
const p = new Promise((res, reject) => {
delayTimer = setTimeout(() => {
console.log('running timeout code...');
if (1 > 0) {
reject('This is NOT caught!');
return;
}
res();
}, 1000);
});
return p;
}
(async () => {
try {
console.log('start async');
await badPromise();
console.log('Made it to the end'); // never gets here
} catch (e) {
console.error('Caught the problem...', e); // should work now
}
})();

Maybe not an answer to what you want, but you could use a pattern like this for setTimeout:
function testErrors() {
new Promise((resolve, reject) => {
setTimeout(() => resolve(), 1000);
}).then(() => {
throw Error("other bad error!");
}).catch(err => {
console.log("Catched", err);
})
}

Why can I return a recursive run of promises?

I have the following code (reconstructed almost 1:1 to work in here):
First of all, understand that bridge_component_start_test is really a call to a constructor object where we generate the initial promise by return new Promise.. I tried to mimick this here. It's my factory for AJAX calls, so, each object creates a promise, which makes a call, which then resolves / rejects with the JSON that it received from the server. I've emulated that response in the resolves below as well.
function recursive_function(data) {
let local_data = $.extend({}, data);
return new Promise((resolve, reject) => {
//The offset gets
local_data.bridge_process_batch_offset++;
if (local_data.bridge_process_batch_offset == 3) {
resolve({
'data': {
'response_data': {
'done_batching': true
}
},
'success': true
})
} else {
resolve({
'data': {
'response_data': {
'done_batching': false,
'bridge_process_batch_offset': local_data.bridge_process_batch_offset
}
},
'success': true
})
}
//For now, no reject.
});
}
function do_the_main_thing(data) {
/**
* Make a local copy of the passed data.
*/
let request_data = $.extend({}, data);
let bridging_data = {
'just_installed_component_demo': request_data.just_installed_component_demo,
'just_installed_component_name': request_data.just_installed_component_name,
'just_installed_component_category': request_data.just_installed_component_category,
'bridge_process_batch_offset': 0
};
const recursively_do_things = () => recursive_function(bridging_data).then(response => {
if (response.data.response_data.done_batching) {
return (response);
} else if (response.data.success == false) {
return response;
} else {
console.log('Went through step ' + response.data.response_data.bridge_process_batch_offset + '!');
if ('bridge_process_batch_offset' in response.data.response_data) {
bridging_data.bridge_process_batch_offset = response.data.response_data.bridge_process_batch_offset;
}
return recursively_do_things ();
}
}).catch(error => {
return error;
});
return recursively_do_things();
}
do_the_main_thing({
'just_installed_component_demo': 'demo-2',
'just_installed_component_name': 'demo-2_post',
'just_installed_component_category': 'post',
'bridge_process_batch_offset': 0
}).then(response => {
console.log('...and now I am done!');
});
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
But notice, in my do_the_main_thing I'm merely returning the response from that promise recursion. Yes, surely, I also return recursively_bridge_component_start but how does JS know to return a promise out of that recursive functionality?
A return is a return. It doesn't have to wait for the Promise to finish, yet it seems it does. In theory, my last line of return recursively_do_things should just instantly return before the Promises are done.
What am I missing here?

But it's quite straightforward. The return value of bridge_component_start_in_test(data) is the return value of recursively_bridge_component_start().
That function in turn returns bridge_component_start_test(data).then(/* do stuff */).catch(/* do other stuff */). That will always be a promise regardless of details of "do stuff" and "do other stuff".
And bridge_component_start_test explicitely returns a promise: return new Promise(//...

You are not returning merely response from recursively_do_things
If you look at the function, you are returning a part of the chain, your return response is just part of the promise chain.
So this part
const recursively_do_things= () => recursive_function(bridging_data).then(response => /* omitted */ );
is returning you a promise chain implying that it first waits for recursive_function to complete, and then does the inner response, after which you can chain other statements
so, since you are returning return recursively_do_things() from your do_the_main_thing(data), it is clear that a promise will be returned.
Update based on comment
Promises are promise aware themselves, which means that if you return a promise in a chain, the promise chain will wait for the returned promise to complete before continuing the next part of the chain.
The requirement for that is that you need to return it, if you just call a function that returns a promise, it will not wait for it.

How can I eliminate these nested Promises?

I've read that you should avoid nested promises in JavaScript, as they tend to be an antipattern, but I'm having trouble figuring out how to avoid them in my particular use case. Hopefully someone with more experience than me can see where I'm going wrong? Any advice would be much appreciated!!
Essentially, I'm retrieving some data asynchronously, processing it and catching a possible Error, and then saving some data asynchronously. Here's a much-simplified example:
class Foo {
changeName(path, newName) {
this.getPage(path) // AJAX call, returns a promise with type Page,
// may throw an Error if the page does not exist.
.then(page=> {
// Some modifications are made to page, omitted here
return page
})
.catch(e=>{
if(e instanceof PageDoesNotExistError) {
return new Page();
}
})
.then(page=> {
page.name = newName;
this.savePage(path, page); // ******
// I want my outer changeName method to return this ^ promise,
// or at least a promise that will resolve when this promise
// resolves, with the same value.
})
}
}
How can I have changeName return a promise that will resolve with the value of this.savePage (the line marked with //******), so that I could do something like this elsewhere:
myFooInstance.changeName('/path', 'New Name').then(page=> {
// Do something with the returned saved page
});

How can I have changeName return a promise that will resolve with the value of this.savePage
Return the promise savePage returns from the then handler. That will resolve the promise created by then to the promise from savePage, meaning that the promise created by then will be fulfilled or rejected depending on what the promise from savePage does. (Details on that terminology in my blog post here if you're interested.)
.then(page=> {
page.name = newName;
return this.savePage(path, page);
})
Separately, you've said you want the caller to be able to use the promise on the return value of changePage but you're not returning anything out of changePage. You need to add return in front of the whole structure so you return the ultimate promise.
changeName(path, newName) {
return this.getPage(path) // AJAX call, returns a promise with type Page,
// ...
(See below for a complete version.)
Side note: You have an error waiting to happen here:
.catch(e=>{
if(e instanceof PageDoesNotExistError) {
return new Page();
}
})
If e is not an instance of PageDoesNotExistError, you're converting the rejection into a resolution with the value undefined, because your catch handler doesn't return an explicit value in that case. If you want to propagate the error instead, you need to do that with throw e or return Promise.reject(e):
.catch(e=>{
if(e instanceof PageDoesNotExistError) {
return new Page();
}
return Promise.reject(e);
})
Bringing all three of those things together:
class Foo {
changeName(path, newName) {
return this.getPage(path)
.then(page=> {
// Some modifications are made to page, omitted here
return page;
})
.catch(e=>{
if(e instanceof PageDoesNotExistError) {
return new Page();
}
return Promise.reject(e);
})
.then(page=> {
page.name = newName;
return this.savePage(path, page);
});
}
}

You would just return the promise and in turn return from any nested promise:
class Foo {
changeName(path, newName) {
return this.getPage(path)
.catch(e => {
if(e instanceof PageDoesNotExistError) {
return new Page();
}
})
.then(page=> {
page.name = newName;
return this.savePage(path, page); // assuming that this is a promise
})
}
}

How to fix the promise anti pattern - Ghost Promise?

I found the term "The Ghost Promise" here, which looks like my case.
I have the code like this:
return Q.Promise(function(resolve, reject) {
firstFunctionThatReturnPromise()
.then(function(firstResult) {
_check(firstResult) ? resolve(firstResult) : return secondFunctionThatReturnPromise();
})
.then(function(secondResult) {
console.log(secondResult);
return thirdFunctionThatReturnPromise(secondResult);
})
.then(function(thirdResult) {
resolve(thirdResult);
})
.catch(function(e) {
reject(e)
});
});
The problem is, even though the _check returns true, it still proceeds to the console.log command (which results in undefined).
In case the _check returns false, things work as expected.
So my question is:
If the behavior described above is normal?
If there is a more elegant way to handle this case?
Update 1: Many questioned that why I use Q.Promise instead of returning the result directly. It's because this is a generic function, shared by other functions.
// Usage in other functions
genericFunction()
.then(function(finalResult) {
doSomething(finalResult);
})
.catch(function(err) {
handleError(err);
});

First off, there's no reason to wrap a new promise around any of this. Your operations already return promises so it is an error prone anti-pattern to rewrap them in a new promise.
Second off, as others have said, a .then() handler has these choices:
It can return a result which will be passed to the next .then() handler. Not returning anything passes undefined to the next .then() handler.
It can return a promise whose resolved value will be passed to the next .then() handler or rejected value will be passed to the next reject handler.
It can throw which will reject the current promise.
There is no way from a .then() handler to tell a promise chain to conditionally skip some following .then() handlers other than rejecting.
So, if you want to branch your promise based on some condition logic, then you need to actually nest your .then() handlers according to your branching logic:
a().then(function(result1) {
if (result1) {
return result1;
} else {
// b() is only executed here in this conditional
return b().then(...);
}
}).then(function(result2) {
// as long as no rejection, this is executed for both branches of the above conditional
// result2 will either be result1 or the resolved value of b()
// depending upon your conditional
})
So, when you want to branch, you make a new nested chain that lets you control what happens based on the conditional branching.
Using your psuedo-code, it would look something like this:
firstFunctionThatReturnPromise().then(function (firstResult) {
if (_check(firstResult)) {
return firstResult;
} else {
return secondFunctionThatReturnPromise().then(function (secondResult) {
console.log(secondResult);
return thirdFunctionThatReturnPromise(secondResult);
})
}
}).then(function (finalResult) {
console.log(finalResult);
return finalResult;
}).catch(function (err) {
console.log(err);
throw err;
});
Even if this is inside a genericFunction, you can still just return the promise you already have:
function genericFunction() {
return firstFunctionThatReturnPromise().then(function (firstResult) {
if (_check(firstResult)) {
return firstResult;
} else {
return secondFunctionThatReturnPromise().then(function (secondResult) {
console.log(secondResult);
return thirdFunctionThatReturnPromise(secondResult);
})
}
}).then(function (finalResult) {
console.log(finalResult);
return finalResult;
}).catch(function (err) {
console.log(err);
throw err;
});
}
// usage
genericFunction().then(...).catch(...)

The behavior is expected. When you chain your .then() statements, you cannot break out of the chain early except by throwing an error.
Your top-level promise (the one returned by Q.Promise()) gets resolved after _check(); but you actually have an inner promise chain that continues to execute.
By specification, then() returns a promise: https://promisesaplus.com/#point-40
You can see for yourself in the source code of Q: https://github.com/kriskowal/q/blob/v1/q.js#L899
For your desired behavior, you'll actually need another nested promise chain.
return Q.Promise(function(resolve, reject) {
firstFunctionThatReturnPromise().then(function(firstResult) {
if (_check(firstResult)) {
resolve(firstResult);
} else {
return secondFunctionThatReturnPromise().then(function(secondResult) {
console.log(secondResult);
return thirdFunctionThatReturnPromise(secondResult);
});
}
});
});

I have never used Q, but everything a promise returns is transformed into a promise and passed to the next .then(). Here, your first .then() don't return anything. So it returns undefined. So undefined is wrapped in a new Promise and passed to the next handler, where you get secondResult == undefined.
You can see it in action in the following CodePen : http://codepen.io/JesmoDrazik/pen/xOaXKE

Is there a shortcut to define and return a rejected promise? [duplicate]

My scenario
I used to have some node.js implementation done using callbacks but I am now refactoring my code to use Promises instead - using Q module. I have the following update() function where the inner _update() function already returns a Promise:
exports.update = function(id, template, callback) {
if (!_isValid(template)){
return callback(new Error('Invalid data', Error.INVALID_DATA));
}
_update(id, template) // this already returns a promise
.then(function() {
console.log('UPDATE was OK!');
callback();
}, function(err) {
console.log('UPDATE with ERRORs!');
callback(err);
});
};
My question
I would like to achieve something like the following:
exports.update = function(id, template) {
if (!_isValid(template)){
// how could I make it return a valid Promise Error?
return reject(new Error('Invalid data', Error.INVALID_DATA));
}
return _update(id, template) // return the promise
.done();
};
Because _update() already returns a promise, I guess changing it this way would be enough (wouldn't be?):
return _update(id, template)
.done();
And... what about if the condition inside the if-clause equals true? How could I refactor
return callback(new Error('Invalid data', BaboonError.INVALID_DATA));
to throw an error to avoid passing the callback into update() and handling that error (or what ever error could ever be returning _update())?
Also, calling update():
myModule.update(someId, someTemplate)
.then(function() { /* if the promise returned ok, let's do something */ })
.catch(function(err) { /* wish to handle errors here if there was any */});
somewhere else in my code:
if there is an error during the promise propagation - it should handle it,
or, if there wasn't an error - it should do some other things
Am I close to what I am expecting? How could I finally achieve it?

I see only two problems.
If you want to explicitly return a rejected promise with a value, you should do that with Q.reject.
Calling .done() on promise means that the promise ends there. It cannot be chained further.
So, your code would look like this
exports.update = function (id, template) {
if (!_isValid(template)) {
return Q.reject(new Error('Invalid data', Error.INVALID_DATA));
}
return _update(id, template);
};
Now, the update function just returns a promise always. Its up to the callers to attach the success or failure handlers to it.