我知道这是一个老问题，但我只是偶然发现了这个线索，这里错误和拒绝之间似乎有一种冲突(至少在许多情况下)，这与经常重复的不要使用异常处理来处理预期情况的建议相冲突。为了说明:如果一个异步方法试图验证一个用户，而认证失败，这是一个拒绝(两种预期的情况之一)，而不是一个错误(例如，如果认证API不可用)。

为了确保我不是在吹毛求疵，我对三种不同的方法进行了性能测试，使用以下代码:

const iterations = 100000;

function getSwitch() {
  return Math.round(Math.random()) === 1;
}

function doSomething(value) {
  return 'something done to ' + value.toString();
}

let processWithThrow = function () {
  if (getSwitch()) {
    throw new Error('foo');
  }
};

let processWithReturn = function () {
  if (getSwitch()) {
    return new Error('bar');
  } else {
    return {}
  }
};

let processWithCustomObject = function () {
  if (getSwitch()) {
    return {type: 'rejection', message: 'quux'};
  } else {
    return {type: 'usable response', value: 'fnord'};
  }
};

function testTryCatch(limit) {
  for (let i = 0; i < limit; i++) {
    try {
      processWithThrow();
    } catch (e) {
      const dummyValue = doSomething(e);
    }
  }
}

function testReturnError(limit) {
  for (let i = 0; i < limit; i++) {
    const returnValue = processWithReturn();
    if (returnValue instanceof Error) {
      const dummyValue = doSomething(returnValue);
    }
  }
}

function testCustomObject(limit) {
  for (let i = 0; i < limit; i++) {
    const returnValue = processWithCustomObject();
    if (returnValue.type === 'rejection') {
      const dummyValue = doSomething(returnValue);
    }
  }
}

let start, end;
start = new Date();
testTryCatch(iterations);
end = new Date();
const interval_1 = end - start;
start = new Date();
testReturnError(iterations);
end = new Date();
const interval_2 = end - start;
start = new Date();
testCustomObject(iterations);
end = new Date();
const interval_3 = end - start;

console.log(`with try/catch: ${interval_1}ms; with returned Error: ${interval_2}ms; with custom object: ${interval_3}ms`);

其中的一些内容是因为我对Javascript解释器的不确定性(我只喜欢一次进入一个兔子洞);例如，我包含了doSomething函数，并将其返回值分配给dummyValue，以确保条件块不会被优化出来。

我的结果是:

with try/catch: 507ms; with returned Error: 260ms; with custom object: 5ms

我知道在很多情况下，不值得花时间去寻找小的优化，但在大型系统中，这些事情可以产生巨大的累积差异，这是一个相当鲜明的对比。

所以…虽然我认为公认的答案的方法是声音的情况下，你期望在一个异步函数中处理不可预测的错误，在这种情况下，拒绝仅仅意味着“你将不得不与计划B(或C，或D…)”我认为我的偏好是拒绝使用自定义响应对象。

编写async函数的一个更好的方法是从一开始就返回一个挂起的Promise，然后在Promise的回调中处理拒绝和解决，而不是在错误时抛出一个被拒绝的Promise。例子:

async foo(id: string): Promise<A> {
    return new Promise(function(resolve, reject) {
        // execute some code here
        if (success) { // let's say this is a boolean value from line above
            return resolve(success);
        } else {
            return reject(error); // this can be anything, preferably an Error object to catch the stacktrace from this function
        }
    });
}

然后你只需在返回的promise上链接方法:

async function bar () {
    try {
        var result = await foo("someID")
        // use the result here
    } catch (error) {
        // handle error here
    }
}

bar()

来源-本教程:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

可能还应该提到的是，您可以在调用异步操作之后简单地链接catch()函数，因为在底层仍然返回一个承诺。

await foo().catch(error => console.log(error));

这样，如果您不喜欢try/catch语法，就可以避免使用它。

我有一个建议，以一种新颖的方法正确处理拒绝，而不需要多个try-catch块。

import to from './to';

async foo(id: string): Promise<A> {
    let err, result;
    [err, result] = await to(someAsyncPromise()); // notice the to() here
    if (err) {
        return 400;
    }
    return 200;
}

哪里去。Ts函数应该从:

export default function to(promise: Promise<any>): Promise<any> {
    return promise.then(data => {
        return [null, data];
    }).catch(err => [err]);
}

感谢迪马·格罗斯曼在以下链接。

这不是对@ tj的回答。克劳德。只是回复注释“实际上，如果异常将被转换为拒绝，我不确定如果它是一个错误，我是否真的会被打扰。我只抛出错误的理由可能并不适用。”

如果你的代码使用async/await，那么用一个Error而不是400来拒绝仍然是一个很好的做法:

try {
  await foo('a');
}
catch (e) {
  // you would still want `e` to be an `Error` instead of `400`
}

我知道这是一个老问题，但我只是偶然发现了这个线索，这里错误和拒绝之间似乎有一种冲突(至少在许多情况下)，这与经常重复的不要使用异常处理来处理预期情况的建议相冲突。为了说明:如果一个异步方法试图验证一个用户，而认证失败，这是一个拒绝(两种预期的情况之一)，而不是一个错误(例如，如果认证API不可用)。

为了确保我不是在吹毛求疵，我对三种不同的方法进行了性能测试，使用以下代码:

const iterations = 100000;

function getSwitch() {
  return Math.round(Math.random()) === 1;
}

function doSomething(value) {
  return 'something done to ' + value.toString();
}

let processWithThrow = function () {
  if (getSwitch()) {
    throw new Error('foo');
  }
};

let processWithReturn = function () {
  if (getSwitch()) {
    return new Error('bar');
  } else {
    return {}
  }
};

let processWithCustomObject = function () {
  if (getSwitch()) {
    return {type: 'rejection', message: 'quux'};
  } else {
    return {type: 'usable response', value: 'fnord'};
  }
};

function testTryCatch(limit) {
  for (let i = 0; i < limit; i++) {
    try {
      processWithThrow();
    } catch (e) {
      const dummyValue = doSomething(e);
    }
  }
}

function testReturnError(limit) {
  for (let i = 0; i < limit; i++) {
    const returnValue = processWithReturn();
    if (returnValue instanceof Error) {
      const dummyValue = doSomething(returnValue);
    }
  }
}

function testCustomObject(limit) {
  for (let i = 0; i < limit; i++) {
    const returnValue = processWithCustomObject();
    if (returnValue.type === 'rejection') {
      const dummyValue = doSomething(returnValue);
    }
  }
}

let start, end;
start = new Date();
testTryCatch(iterations);
end = new Date();
const interval_1 = end - start;
start = new Date();
testReturnError(iterations);
end = new Date();
const interval_2 = end - start;
start = new Date();
testCustomObject(iterations);
end = new Date();
const interval_3 = end - start;

console.log(`with try/catch: ${interval_1}ms; with returned Error: ${interval_2}ms; with custom object: ${interval_3}ms`);

其中的一些内容是因为我对Javascript解释器的不确定性(我只喜欢一次进入一个兔子洞);例如，我包含了doSomething函数，并将其返回值分配给dummyValue，以确保条件块不会被优化出来。

我的结果是:

with try/catch: 507ms; with returned Error: 260ms; with custom object: 5ms

我知道在很多情况下，不值得花时间去寻找小的优化，但在大型系统中，这些事情可以产生巨大的累积差异，这是一个相当鲜明的对比。

所以…虽然我认为公认的答案的方法是声音的情况下，你期望在一个异步函数中处理不可预测的错误，在这种情况下，拒绝仅仅意味着“你将不得不与计划B(或C，或D…)”我认为我的偏好是拒绝使用自定义响应对象。