CODEWITHSUNDEEP
javascriptpromise
Flame_Phoenix
Flame_Phoenix

Reputation: 17574

Resolving/Rejecting Promises, what are the differences?

Story

All my life I have always used the following code pattern in my promises:

const => new Promise((resolve, reject) => {
    //do some work
    if(err !== undefined){
        reject(err);
        return;
    }

    if(someCondition){
        resolve(1);
        return;
    }

    resolve(2);
});

However, recently one of my pupils presented me with an interesting code:

const => new Promise((resolve, reject) => {
    //do some work
    if(err !== undefined) return reject(err);

    if(someCondition) return resolve(1);

    resolve(2);
});

My first reaction was: "You should do it my way because... (silence followed)"

Problem

I tried finding a logical explanation for the difference and I couldn't find one.

I tried checking the MDN documentation for Promises to see if resolve or reject could return something other than undefined but I didn't find it either.

Question:

So now I am left with one question: - What are the differences (if any) between my approach and my pupil's approach, code functionality wise? (AKA, will they always return the same output and have the same behaviour under the same conditions?)

Upvotes: 4

Views: 79

Answers (4)

T.J. Crowder
T.J. Crowder

Reputation: 1074158

What are the differences (if any) between my approach and my pupil's approach, code functionality wise?

In this specific situation, there aren't any, for three reasons:

  1. The resolve and reject functions passed to the Promise executor (the function you pass new Promise) are defined as returning undefined. So return resolve(...) is effectively resolve(...); return undefined;

  2. The Promise constructor doesn't use the return value of the executor, so even if #1 weren't true, it still wouldn't matter.

  3. In a function, the difference between return; and return undefined; is present at a specification level, but not observable in code. That is, in code, they do exactly the same thing, even though the spec differentiates them slightly.

It's probably worth noting that while it doesn't make a functionality difference, it makes a semantic difference. return resolve(...) says "call resolve and return its return value" — suggesting that that return value has meaning and matters to the code. It doesn't, so return resolve(...) is misleading to people maintaining the code later. As a matter of style, I don't recommend it. (Mind you, if it becomes common enough, it becomes an idiom, and the confusion to resolved by knowing the idiom, but...) If saving the line is important to you, just do resolve(...); return; (or better yet, don't worry about the extra line, or make your logic not require the return at all). But your question was about differences in functionality, so...

That said, it's dangerous to generalize this to other situations where the function you're calling may not return undefined, or where the return value of your function is used.

Upvotes: 4

Jason
Jason

Reputation: 534

From the MDN,

We call resolve(...) when what we were doing asynchronously was successful, and reject(...) when it failed.

So yes, the code examples will always return the same thing, though as another person has mentioned it's not a very good code snippet.

Upvotes: 0

Norix
Norix

Reputation: 33

There is no difference in the 2 code examples, they will both act exactly the same. The only difference is if you had to perform additional logic before resolving / rejecting, e.g. clearing variables, the first approach would be more readable. Other than that it is just readability. You can remove the {} around conditionals if you only need to execute 1 line within the condition

Upvotes: 0

Ry-
Ry-

Reputation: 224886

They will always behave in exactly the same way, yes, as the resolve and reject functions passed to the executor both return undefined and return undefined is equivalent to return (and the promise constructor doesn’t use the value you return anyway).

Typically, you won’t want to use the Promise constructor much at all, though. This one looks like something that could make use of Promise.resolve and Promise.reject, for example:

// do some work
if (err !== undefined) {
    return Promise.reject(err);
}

if (someCondition) {
    return Promise.resolve(1);
}

return Promise.resolve(2);

Upvotes: 1

Related Questions