There seems something inherently wrong with having to define a Promise's callback as asynchronous:
return new Promise(async (resolve, reject) => {
const value = await somethingAsynchronous();
if (value === something) {
return resolve('It worked!');
} else {
return reject('Nope. Try again.');
}
});
This is apparently an antipattern and there are coding problems which can arise from it. I understand that it becomes easier to fail to catch errors here, even when placing await statements inside try/catch blocks.
My first question is, what's the best way to code something like this, when one wants to forward a Promise with different resolve/reject values? With then/catch? I.e.
return new Promise((resolve, reject) => {
somethingAsynchronous().then(value => {
if (value === something) {
return resolve('It worked!');
} else {
return reject('Nope. Try again.');
}
}); // errors would now be propagated up
});
Or do you just take it out the Promise constructor altogether as suggested here?
async function outerFunction() {
const value = await somethingAsynchronous();
return new Promise((resolve, reject) => {
if (value === something) {
return resolve('It worked!');
} else {
return reject('Nope. Try again.');
}
});
}
But what if you have several await statements in the outerFunction(), i.e. a linear code block calling several asynchronous functions. Would you then have to create and return a new Promise every time?
But then how do you account for code such as this?
async function outerFunction() {
if (someSynchronousCheck()) {
return 'Nope. Try again.' // another reject case
}
const value = await somethingAsynchronous();
// ...
}
I have the feeling that I'm making this more complicated than it should be. I'm trying to avoid nesting callbacks/chaining then/catch blocks without creating more problems in the future.
My final question is, why is the callback passed to a Promise not inherently async? It is already wrapped within a promise and expects the resolve/reject functions to be called asynchronously.
You do this:
async function outerFunction() {
const value = await somethingAsynchronous();
if (value === something) {
return 'It Worked!';
}
throw Error('Nope. Try again.');
}
Using async wraps the result of outerFunction with a Promise.
If you want that wrapping promise to resolve to something, just return it from the async function. If you want the wrapping promise to be rejected, throw an error inside the async function.
But then how do you account for code such as this?
async function outerFunction() {
if (someSynchronousCheck()) {
throw Error('Nope. Try again.');
}
const value = await somethingAsynchronous();
// ...
}
new Promise(async (resolve, reject) => { ... }) is relatively new antipattern. It results in creating 2 promise objects instead of 1, uncaught errors that happen inside constructor cannot be caught with try..catch and result in unhandled rejection.
Considering that promise asynchronous code can be handled with async..await, current use case for Promise constructor is non-promise asynchronous code, e.g.:
new Promise(resolve => setTimeout(resolve, 1000))
When Promise constructor contains synchronous code or involves other promises, a promise should be constructed with async function. A drop-in replacement is async IIFE:
return (async (resolve, reject) => {
const value = await somethingAsynchronous();
if (value === something) {
return 'It worked!';
} else {
throw 'Nope. Try again.';
}
})();
If the need for Promise constructor still presents when being used together with async, Promise constructor should be moved down in hierarchy so it won't wrap any async function.
My final question is, why is the callback passed to a Promise not inherently async? It is already wrapped within a promise and expects the resolve/reject functions to be called asynchronously.
async function isn't just a function that is executed asynchronously, it returns another promise that is supposed to be utilized - or at least handled with catch. Promise isn't supposed to utilize a promise that is returned from constructing function.
The constructor can resolve on same tick and doesn't necessarily have to be asynchronous.
Promise.resolve(1);
is similar to
Promise(resolve => resolve(1))
and not to
Promise(resolve => setTimeout(() => resolve(1)))
You can also chain the promises yourself by simply doing this:
return new Promise((resolve, reject) => {
somethingAsynchronous().then((value) => {
if (value === something) {
return resolve('It worked!');
} else {
return reject('Nope. Try again.');
}
}, (error) => { reject(error); });
});
I've been using this for some time and it works perfectly for me.
Related
Written below is an example of my code I usually do.
What I did is..
Add try-catch for a promise function with async-await.
Do no add try-catch for a promise function without async-await.
What I want to know is my code is alright, and it is anti-pattern or not.
Thank you in advance.
const readStatusAll = data => {
return new Promise( async (resolve, reject) => {
try {
const category = await CoreStatus.findAll()
resolve(category)
} catch(err) {
reject(err)
}
})
}
// Promise without Await
const readStatusAll = data => {
return new Promise( async (resolve, reject) => {
CoreStatus.findAll()
resolve(category)
}
})
}
What I want to know is my code is alright, and it is anti-pattern or not.
The first one will work properly, but is an anti-pattern.
The second one will not work properly.
Neither of the code blocks you show is the recommended way to do things because they are both needlessly wrapping an existing promise in another manually created promise. This is referred to as an anti-pattern. This first version will actually work properly, but it contains a bunch of useless code (thus making it an anti-pattern) and with a little more complexity in the function, it's very easy to make coding mistakes (which is why, in addition to the useless code it contains, its an anti-pattern).
const readStatusAll = data => {
return new Promise( async (resolve, reject) => {
try {
const category = await CoreStatus.findAll()
resolve(category)
} catch(err) {
reject(err)
}
})
}
It can instead be this:
const readStatusAll = data => {
return CoreStatus.findAll();
}
The caller will receive the promise as the return value and can then use either .then() and .catch() or await and try/catch. Since you aren't doing anything with the error, other than propagating it, you don't need to catch the error locally - you can just let it propagate back to the caller.
Your second version is just not correct at all:
// Promise without Await
const readStatusAll = data => {
return new Promise( async (resolve, reject) => {
CoreStatus.findAll()
resolve(category)
}
})
}
Because you're not paying any attention to any asynchronous return from CoreStatus.findAll() so you will resolve this manual wrapper promise long before the database call is actually done. In fact, this isn't even legal code as you have improper bracing.
Perhaps you meant to call resolve(category) in some callback or .then() handler associated with CoreStatus.findAll(). But, even if you did that, you still wouldn't be propagating errors back to the caller. This is not the way to do things.
With promises, is it bad practice to leave out the use of reject? If I just want to return a Promise to ensure this function is run in it's entirety and not block whatever follows this function.
function testFunc() {
return new Promise((resolve,reject) => {
// do stuff
resolve(true);
})
}
testfunc().then(() => { // additional stuff});
If there is a chance of the do stuff throwing an error, then you should make sure to use reject and call it in case there's an error, so that the caller can see that there was a problem and (hopefully) handle it appropriately. For example, you wouldn't want to do:
function testFunc() {
return new Promise((resolve,reject) => {
getApi((error, result) => {
resolve(result);
});
});
}
but instead
function testFunc() {
return new Promise((resolve,reject) => {
getApi((error, result) => {
if (error) reject(error);
resolve(result);
});
});
}
If there's really no chance of the contents of the function erroring (barring logic bugs that could be unknowingly present in any code), then reject won't help you, because you don't really have any place suitable to put it. For example:
function someWeirdPromiseFunctionThatBlocks() {
return new Promise((resolve) => {
for (let i = 0; i < 1e5; i++) {
}
resolve();
});
}
Note that if you just want to:
not block whatever follows this function.
then just returning a Promise won't accomplish that, because the Promise constructor will run all of its code synchronously until it encounters something asynchronous (like getApi). To avoid blocking the running of sync code below, use Promise.resolve or setTimeout, eg:
function testFunc() {
return Promise.resolve()
.then(() => {
// do other stuff
});
No, its not necessary at all. reject is meant to be used in a similar way as one might use throw - it's for errors that happen.
In fact, if you're familiar with javascript's async/await syntax, this async function...
async function doSomething() {
throw new Error('Oh no!')
}
...roughly translates to this:
function doSomething() {
return Promise.reject(new Error('Oh no!'))
}
which shows how reject is intended to be used wherever you might normally throw an error.
Here's an example promise that I use often where there isn't any "reject" that would make sense:
const wait = ms => new Promise(resolve => setTimeout(resolve, ms))
wait(1000).then(() => console.log('done'))
Many others such examples exist.
in one of youtube tutorial videos about promises I found following code:
let cleanRoom = function() {
return new Promise((resolve, reject) => {
resolve();
});
};
let removeGarbage = function() {
return new Promise((resolve, reject) => {
resolve();
});
};
let winIcecream = function() {
return new Promise((resolve, reject) => {
resolve();
});
};
cleanRoom().then(function(){
return removeGarbage();
}).then(function() {
return winIcecream();
}).then(function() {
console.log('finished');
})
Why the promises aren't chained like that the every .then word is after the previous promise? I mean, why for example .then is not immediately after removeGarbage() but it is after the cleanRoom().then(), how is it happening that the winIcecream() will run after resolving the removeGarbage promise?
Also do I need to type return declaring every promise like in the code above? If yes, why do I need to do so?
Your initial questions may be answered by rewriting things to variable assignments.
I'm using arrow function syntax to implicitly return the new expression here; if you're using regular functions, then yes, you do have to return the new chained promise if you want to run them in sequence.
const roomCleanedPromise = cleanRoom();
const roomCleanedAndGarbageTakenOutPromise = roomCleanedPromise.then(() => removeGarbage());
const roomCleanedAndGarbageTakenOutAndIcecreamWonPromise = roomCleanedAndGarbageTakenOutPromise.then(() => winIcecream());
const finishedPromise = roomCleanedAndGarbageTakenOutAndIcecreamWonPromise.then(() => console.log('finished'));
However things are easier written using the more modern async/await syntax - the YouTube tutorial you mention is a little outdated, perhaps.
async function cleanRoom() {
console.log('Cleaning room.');
// this could do other async things or just take a while
return {room: 'clean'}; // just to demonstrate a return value
}
async function removeGarbage() {
console.log('Removing garbage.');
// this could do other async things or just take a while
return {garbage: 'removed'};
}
// third function elided for brevity
async function doAllTheThings() {
const roomStatus = await cleanRoom();
const garbageStatus = await removeGarbage();
console.log('finished');
}
The purpose of using a fulfillment handler (the functions passed to then in your example) is to wait for the promise to be fulfilled and then, at that point, do something else.
The goal of that code (apparently) is to wait until the cleanRoom promise is fulfilled, then start the removeGarbage process, and then when that is fulfilled, start the winIcecream process. It's also worth noting that if cleanRoom's promise was rejected instead of being fulfilled, removeGarbage wouldn't happen at all, because it's in a fulfillment handler, not a rejection handler.
If you did this instead:
cleanRoom().then(function() { /*...*/ });
removeGarbage().then(function() { /*...*/ });
winIcecream().then(function() { /*...*/ });
...all three processes would be started immediately and run in parallel (to the extent whatever async process they're modelling can run in parallel with other JavaScript code). There'd be no coordination between them at all.
...how is it happening that the winIcecream() will run after resolving the removeGarbage promise...
then, catch, and finally create and return new promises. Those promises are fulfilled or rejected based on what happens to the promise they were called on and what happens in or is returned by their handler. So for example:
doThis()
.then(function() { return doThat(); })
.then(function() { console.log("done"); });
Let's call the promise from doThis() "Promise A". Calling then on it creates a new promise ("Promise B"), that will either be rejected (if Promise A is rejected) or will call its handler if Promise A is fulfilled. Promise B is resolved to whatever that handler returns. In the code above, suppose Promise A is fulfilled and doThat() returns a promise ("Promise C"). Now, Promise B is resolved to Promise C — whatever happens to Promise C is what will happen to Promise B. If Promise C is fulfilled, Promise B is fulfilled, and the second handler with the console.log is called.
The MDN article on using promises may be helpful.
Your suggestion / thinking I mean, why for example .then is not immediately after removeGarbage() but it is after the cleanRoom().then() is wrong.
Each promise ( .then ) is not execute immediately.
You can take a look at your example ( little edited by me )
const cleanRoom = () => new Promise((resolve, reject) => {
resolve();
});
const removeGarbage = () => new Promise((resolve, reject) => {
resolve();
});
const winIcecream = () => new Promise((resolve, reject) => {
resolve();
})
cleanRoom().then(function(){
console.log('second');
return removeGarbage();
}).then(function() {
return winIcecream();
}).then(function() {
console.log('finished');
})
console.log('first');
You should read more how the event loop works.
I have a function called "test_sheet" that is supposed to return a value. that value will then be passed to a tester function which will tell me if I passed or failed the test.
inside my "test_sheet" I have a few async operations which are handled by promises.
now, how can I return a (non-promise) value from my test_sheet function.
function test_sheet()
{
//all my logic will go here
new Promise(function(resolve, reject)
{
//simulating an async operation
setTimeout(() => resolve(true), 1000);
})
.then(function(res){return res});
}
function tester()
{
//not allowed to change this function in any way
if(test_sheet() == true)
console.log("pass!");
else
console.log("fail!");
}
tester();
Is there any better way of doing this?
Well, technically it is possible, tester() may reamain intact:
var test_sheet=false;
function start_test()
{
//all my logic will go here
new Promise(function(resolve, reject)
{
//simulating an async operation
setTimeout(() => resolve(true), 1000);
})
.then(res => {
test_sheet=true;
tester();
});
}
function tester()
{
//not allowed to change this function in any way
test_sheet == true ? console.log("pass!") : console.log("fail!");
}
//tester();
start_test();
But the test starts with start_test() now, and test_sheet became a variable, with the sole purpose of acting as an argument - which could not be added to testing() without modifying it.
A nonworking bad design is transformed to working bad desing this way.
test_sheet() always returns a promise so try to get it resolved using async await or .then which feeds into the tester() function.
call you function this way:
test_sheet().then(function(test_sheet){
tester(test_sheet)})
for this you need to pass the boolean return value from test_sheet() to tester(test_sheet)
If you handle asynchronous code you have to use promise or callback and handle with async/await to change them to synchronous code
For example
function test_sheet()
{
//all my logic will go here
return new Promise(function(resolve, reject) {
//simulating an async operation
setTimeout(() => resolve(true), 2000);
})
}
async function tester()
{
//not allowed to change this function in any way
await test_sheet() == true ? console.log("pass!") : console.log("fail!");
}
tester();
New at promises, so feel free to be verbose.
I am writing a function "extra_promises_at_start_and_end" that returns a promise to do something.
This function may know immediately that it will fail (ie: return a promise that is rejected). Question 1: Is there something like Promise.give_me_a_rejected_promise(..) or do I have to create a promise and reject it just like my code does?
Similarly, my function "extra_promises_at_start_and_end" calls other functions that return promises. At the end of this async chaining of work, I need to some final processing. Question 2a/2b: Since my function returns a promise, I need to create a promise to do this last bit of work. Is this correct that I need to create a promise and immediately accepted or reject it? Is there a Promise.give_me_a_rejected_promise(..).
My code works as expected, just feels like I am missing something, and so generating redundant code.
Code in question:
// this is the function that may have redundant code
// see question 1 and 2
function extra_promises_at_start_and_end() {
// fake out some module scope variable that indicates if this call is allowed to proceed or not
let ok_to_proceed = Math.random() > 0.5
// this function "extra_promises_at_start_and_end returns" a promise,
// Question 1: I need to create a Promise just to reject it immediatly?
if (!ok_to_proceed) {
return new Promise((resolve, reject) => { reject("failed before starting anything") }) // feels wrong
}
// do 5 things in sequence
return another_module_promise_to_do_something(1).then(() => {
return another_module_promise_to_do_something(2)
}).then(() => {
return another_module_promise_to_do_something(3)
}).then(() => {
return another_module_promise_to_do_something(4)
}).then(() => {
return another_module_promise_to_do_something(5)
}).then(() => {
// need to do something after the above 5 tasks are done,
console.log("doing something after all 5 things are done")
// this function "extra_promises_at_start_and_end" returns a promise,
// Question 2a: I need to create a promise just to resolve it immediatly?
return new Promise((resolve, reject) => { resolve(); }) // feels wrong
}).catch((id) => {
// this function extra_promises_at_start_and_end returns a promise,
// Question 2b: I need to create one just to reject it immediatly?
return new Promise((resolve, reject) => { reject(id); }) // feels wrong
})
}
The caller of this code is expecting a promise.
// run the test
console.log("calling something that will return a promise to let me know when it's done");
extra_promises_at_start_and_end()
.then(() => {
console.log("done :)")
}).catch((id) => { console.log("failed id = " + id) })
Finally, a stub for testing my function
// pretend this is a complex task (ie: not suitable for inlining)
// done by some other module
// it returns a promise
function another_module_promise_to_do_something(id) {
console.log("starting " + id)
let P = new Promise((resolve, reject) => {
console.log(" inside promise " + id)
setTimeout(() => {
if (Math.random() > 0.1) {
console.log(" finished " + id);
resolve();
} else {
console.log(" failed " + id)
reject(id);
}
}, Math.random() * 1000)
})
return P;
}
If this is the way it is supposed to be done, then let me know and I will stop searching for the correct way to use promises.
What I learned is:
Promise.resolve(value) method returns a Promise object that is resolved with the given value. So anyone calling my function can do a then on the response.
Promise.reject(reason) method returns a Promise object that is rejected with the given reason. So any chaining will fail as needed.
Any return value in then will get encapsulated in a promise. Feels like this obscures the intent. So not using.
My new function is as follows:
function promise_something() {
// fake out some module scope variable that indicates if this call is allowed to proceed or not
let ok_to_proceed = Math.random() > 0.5
if (!ok_to_proceed) {
return Promise.reject("failed before starting anything")
}
// do 5 things in sequence
return another_module_promise_to_do_something(1).then(() => {
return another_module_promise_to_do_something(2)
}).then(() => {
return another_module_promise_to_do_something(3)
}).then(() => {
return another_module_promise_to_do_something(4)
}).then(() => {
return another_module_promise_to_do_something(5)
}).then(() => {
// need to do something after the above 5 tasks are done,
console.log("doing something after all 5 things are done")
return Promise.resolve()
}
The then() and catch() functions of a Promise return a Promise.
Your last big chunk of code is indeed redundant. If you needed to do any processing after the 5th chained invocation of then(), you could just chain another then().
Here's a more bare-bones version of your code to illustrate:
const countFromOneToFive = () => {
if (Math.random() > 0.5) {
return Promise.reject("Cosmic radiation ruined your promises. Great.");
}
return Promise.resolve([])
.then((countToFive) => {
countToFive.push(1);
return countToFive;
})
.then((countToFive) => {
countToFive.push(2);
return countToFive;
})
.then((countToFive) => {
countToFive.push(3);
return countToFive;
})
.then((countToFive) => {
countToFive.push(4);
return countToFive;
})
.then((countToFive) => {
countToFive.push(5);
return countToFive;
});
};
countFromOneToFive()
.then((countToFive) => {
countToFive.forEach((number) => console.log(number));
})
.catch((error) => {
console.log(error, "Curses!");
});
You can use Promise.reject() to just return a rejected Promise. This is handled in the catch statement in the bottom.
You can do all of your processing with as many then() invocations as you want. You can simply return after your final then() to have a Promise. From there, treat it like any promise and append then()s and catch()s as you see fit.
1: Is there something like Promise.give_me_a_rejected_promise(..) or do I have to create a promise and reject it just like my code does?
like Promise.reject(err)?
// Question 2a: I need to create a promise just to resolve it immediatly?
The point where this is written in your code is inside a promise chain. You don't need to do anything at all (in that context), to return a resolved Promise, except maybe not throwing.
This Promise will resolve to any value you return, except undefined. And if you return undefined (explicitely or implicitely), this Promise will resolve to the last value before that, in the Promise chain.
Only if you need to explicitely resolve to undefined you'd have to return Promise.resolve().
// Question 2b: I need to create one just to reject it immediatly?
Still inside the Promise chain: Since a rejected value is like a thrown Error in sync code, all you need to do here is to throw.
But that is pointless in the context you asked. Why catching an Error, just to immediately throw the very same Error, without doing anything else in that catch-block.
So your code could be like
function extra_promises_at_start_and_end() {
// fake out some module scope variable that indicates if this call is allowed to proceed or not
let ok_to_proceed = Math.random() > 0.5
if (!ok_to_proceed) {
return Promise.reject("failed before starting anything");
}
// do 5 things in sequence
return another_module_promise_to_do_something(1)
.then(() => another_module_promise_to_do_something(2))
.then(() => another_module_promise_to_do_something(3))
.then(() => another_module_promise_to_do_something(4))
.then(() => another_module_promise_to_do_something(5))
.then(() => {
// need to do something after the above 5 tasks are done,
console.log("doing something after all 5 things are done")
return null; //so the previous value is no longer propagated by this Promise
})
//.catch(id => { throw id }) //is pointless.
}
When you say "This Promise will resolve to any value you return". So returning new Promise((resolve, reject) => { resolve 100}).then .... blaw blaw blaw is the same as 100.then .. blaw blaw blaw ?
Not exactly. Inside a Promise chain, returning a plain value like 100 or a Promise that resolves to 100 (like return Promise.resolve(100)) is equivalent in result ...
var foo1 = somePromise.then(() => {
//do something
return 100
})
//is equivalent in result to
var foo2 = somePromise.then(() => {
//do something
return Promise.resolve(100);
})
//or to
var foo3 = somePromise.then(() => {
//do something
return new Promise(resolve => resolve(100));
})
foo1, foo2, foo3 are all promises that resolve to the value 100 after somePromise has finished. That's equivalent in result.
... but you can't call then() on a number.
//you can do
somePromise.then(() => {
//do something
return 100
}).then(...)
//or sometimes you want to do
somePromise.then((value) => {
//usually because you need `value` inside `.then(...)`
return somethingAsync().then(...)
})
//but you can NOT do
somePromise.then(() => {
//do something
return 100.then(...)
})