Definitely learned some new stuff there.
The moderators of this message board, otatop, L.Washington, WichitaDM, Yuv, JonnyA, RiskyFlush, and SvenO, are cowards who let abusers dox and harrass other long time posters.
3 Likes
The moderators of this message board, otatop, L.Washington, WichitaDM, Yuv, JonnyA, RiskyFlush, and SvenO, are cowards who let abusers dox and harrass other long time posters.
Never in doubt
Seems like you need to move up to where you respect their coding questions.
But seriously though, would it be wrong to consider this an indication that you need to be setting your sights even higher.
I’m very confused and am not sure what’s going on there. But if you want to make async calls in parallel, use Promise.all([foo(), bar()]). async/await doesn’t work for parallel calls.
Also FYI nothing is “starting” until you use await. You can have a function that returns a promise. But it’s not actually executed (like say making an HTTP call) until you call await. So you’re not really starting anything at the top of the function. The actual work will always kick off and finish within the await statement, then move on to the next line.
I believe the part of an async function up to the first await is equivalent to the body of a promise, which means it runs synchronously. So you would need to handle any errors that could arise when you call it.
Yeah I was confused. I didn’t know what asyncFoo() and asyncBar() looked like. So I was thinking maybe they return another async function to be executed later. But I guess then your second statement would have to be await foo() not await foo.
If you don’t return a promise, like you’re doing here, JS implicitly wraps the returned value in a promise. So you’re instantly getting a promise back for the async function, and then trying to await it later in the code. I’ve never seen that done, and I don’t know how it will behave.
But what you want is Promise.all([one(), two()]). Or maybe Promise.allSettled().
This might be what’s happening to you:
More on the subject:
Unhandled rejections are a Bad Thing™ (so much so that soon, Node.js will abort the process on truly unhandled rejections, just like unhandled exceptions — because that’s what they are), so best to avoid the “get the promise then
awaitit” pattern in your question.
This is a bad practice. Never use multiple await for two or more async parallel tasks because you will not be able to seriously handle errors. It works only for positive scenario but in negative scenario (async tasks rejection) you will always end with unhandled errors although you use try/catch. You must always use Promise.all for async parallel tasks. See my answer here : stackoverflow.com/a/54291660/3826175 If you need to handle errors globally and separately use this:
try { let [val1, val2] = await Promise.all([ task1().catch(e => ...), task2().catch(e => ...) ]); } catch(e) { }
1 Like
Promise.all isn’t quite right because it will wait for bar even if you don’t need it. You can roll your own combinator like this:
function firstSuccess(fn1, fn2) {
const wrapSuccess = result => { return {success: true, result} };
const wrapRejection = result => { return {success: false, result} };
const wrappedFn2 = fn2().then(wrapSuccess).catch(wrapRejection);
return new Promise((resolve, reject) => {
fn1()
.then(wrapSuccess)
.catch(() => wrappedFn2)
.then(({success, result}) => {
success ? resolve(result) : reject(result)
})
})
}
The basic idea is that you wrap the second function to hold the error until you need it. Then you just call the first function, replace it with the promise from the second function if it fails, and have a final then block to decide whether the promise as a whole succeeded or not. The key point is that the returned promise will resolve immediately if foo succeeds, and will only wait for bar if it needs to.
EDIT: My JS hot take is that async/await is actually kind of insidious, because it doesn’t really abstract the complexity of asynchronous programming away, it just hides it so it’s not obvious what’s going on. When it works like expected, that’s great because it makes the code easy to read, but when stuff goes wrong, it’s hard to understand why. Promises are a lot more principled about only hiding the implementation details that are actually abstracted away, so it’s a good idea to drop down to writing (or at least thinking) in terms of promises if async code isn’t working as expected.
The moderators of this message board, otatop, L.Washington, WichitaDM, Yuv, JonnyA, RiskyFlush, and SvenO, are cowards who let abusers dox and harrass other long time posters.
I like async/await because 95% of the time I want sequential, and I usually don’t care about catching the rejection in node lambdas. I just let it barf.
You can also use Promise.any() for that, if on node 15 or higher.
In my situation - which is to say that I’m gambling for a living and have no clue whether it will keep providing - I’m pleased about the rise of full-remote work, because I think it’ll make companies more comfortable with hiring older employees. I’ve heard concerns before about older people fitting in with workplace culture, full-remote makes those concerns near obsolete.
Grunch:
3 Likes
Why does VS Code sometimes forget the workspace and start up with all the editors closed? It is random and infuriating, and asking the internet is very not helpful.
I had my first ever technical interview Tuesday and just got the result back:
They didn’t offer me the job I interviewed for.
But they offered me a job a level up instead!
Time to go drink some bourbon…
21 Likes
Congratulations!
1 Like
Lol yellow hearts
1 Like
But not enough for anybody to tell me why VS Code randomly forgets all my open editors :(