Home > database >  clarification about promises in javascript
clarification about promises in javascript

Time:09-30

I am confused with certain parts regarding promises, I have read multiple articles and I have seen multiple videos and I want to ask a few things:

from what I understand currently, when a promise is created is starts running.

Do I need to await on the promise if the value that returned from the promise is not used in the code ?

a scenario for that is: let's say I am processing a task in my system and I want to log the information to mongodb, when I invoke the insert function I get a promise back. the execution beings but I don't care about the result of it

if I am not awaiting and there is an error I wouldn't be able to handle it.

A followup question to the question above:

from what I read whenever I await it actually blocks the execution of the async function, but if it blocks the execution of the function how doesn't it block the rest of the eventloop ?

CodePudding user response:

When a promise is created is starts running

Yes, but no. A promise does not run, a promise is only a contract you receive by a part of code that will be used to notify you of the outcome. So the promise does not run, is the mean that has been created for you after you requested a task to be executed.

So typically if a promise has been handled to you there is something 'running'. But Promise may be used differently and there may be something 'waiting'.

A promise is not linked to the execution of the task hence it can not start nor stop it.

Do I need to await on the promise if I'm not interested in the outcome

No, you are not required to. But keep in mind that not handling promise exceptions is being deprecated and may result in system failure. You should always handle (or let bubble) exceptions.

There would be a failure if there is an unhandled promise rejection. In synchronous code this is equivalent to an uncaught thrown error. Until now(-ish) uncaught promise rejections were tolerated but there isn't a really good reason for that. Node is moving to treat them the same as any other error that bubbles to the top.

VLAZ

You are considering promises only with async/await but the underlying Promise api is .then() and .catch(). Using this API you can use promises in a 'fire-and-forget' fashion:

async function Do() {
  await before();
  asyncDbCall().catch(err => console.error(err))
  await after();
}

In this example you are not waiting for asyncDbCall() but still .catch(err => console.error(err)) will result in the error being logged (some time in the future, probably even after Do() has completed).

Or you can branch off the execution to other async executions, take this complex example:

async function Do() {
    await before();
    // This will execute AFTER before() & only if before() succeeded
    asyncDbCall()
        .then(async value => {
            // This will execute after `asyncDbCall()` and only if it succeeded
            await something(value);
            // We reach here after `something()` and only if succeeded
        })
        .catch(err => {
            // This will execute if `asyncDbCall()` fails of IF ANYTHING
            // within `async value => {}` fails
            console.error(err);
        })
    // This will execute AFTER before() and only if before() succeeded and
    // asyncDbCall() call (but not Promise) succeeded
    await after();
}

await it actually blocks the execution of the async function

Await stops the async function (hence also anything that is awaiting for the function) but does not affect anyway the event loop.

CodePudding user response:

from what I understand currently, when a promise is created is starts running.

It is not. It has its internal state set to pending. Promise's constructor takes a callback as an argument, and in turn provides it with resolve and reject callbacks.

What it also does is that it allows to provide a number of actions that happen when it's state changes to resolved or rejected. Outside of async/await, you might know them as .then and .catch instance methods of Promise class. Once the state is changed, they will be executed.

Do I need to await on the promise if the value that returned from the promise is not used in the code?

No, that is entirely up to you.

a scenario for that is: let's say I am processing a task in my system and I want to log the information to mongodb, when I invoke the insert function I get a promise back. the execution beings but I don't care about the result of it

if I am not awaiting and there is an error I wouldn't be able to handle it.

You can still use .catch to handle the error without awaiting for the Promise to finish

A followup question to the question above:

from what I read whenever I await it actually blocks the execution of the async function, but if it blocks the execution of the function how doesn't it block the rest of the eventloop?

Promises have nothing to do with the event loop.

You can read more about the EventLoop here.

  • Related