javascript - 解决/拒绝 promise ，有什么区别？

Question

故事

我一生都在 promise 中使用以下代码模式:

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

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

    resolve(2);
});

然而，最近我的一个学生向我展示了一个有趣的代码:

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

    if(someCondition) return resolve(1);

    resolve(2);
});

我的第一 react 是:“你应该按照我的方式去做，因为......(沉默之后)”

问题

我试图为这种差异找到合乎逻辑的解释，但找不到。

我尝试检查 MDN 文档中的 Promises 以查看 resolve 或 reject 是否可以返回 undefined 以外的内容，但我也没有找到它。

问题:

所以现在我只剩下一个问题: - 我的方法和我的学生的方法在代码功能方面有什么区别(如果有的话)？ (也就是说，它们是否会总是返回相同的输出并在相同的条件下具有相同的行为？)

Answer 1

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

在这种特定情况下，没有任何原因，原因有以下三个:

1. 传递给Promise执行器的resolve和reject函数(你传递给new Promise的函数)are defined as返回 undefined。所以 return resolve(...) 实际上是 resolve(...);返回未定义；

2. Promise 构造器 doesn't use the return value of the executor ，所以即使 #1 不是真的，也没关系。

3. 在函数中，return; 和 return undefined; 之间的区别存在于规范级别，但在代码中无法观察到。也就是说，在代码中，它们做的事情完全相同，尽管规范对它们略有不同。

---

可能值得注意的是，虽然它不会产生功能差异，但会产生语义差异。 return resolve(...) 说“调用 resolve 并返回它的返回值”——表明该返回值对代码有意义和重要。它没有，所以 return resolve(...) 会误导以后维护代码的人。至于风格，我不推荐。 (请注意，如果它变得足够普遍，它就会成为一个成语，并且通过了解该成语来解决困惑，但是......)如果保存行对你很重要，只需执行 resolve(...) ; return; (或者更好的是，不用担心额外的行，或者让你的逻辑根本不需要 return )。但是你的问题是关于功能上的差异，所以......

---

也就是说，将其推广到您正在调用的函数可能不会返回 undefined 或您的函数的返回值被使用的其他情况是危险的.