异步API是否应该同步抛出？

Question

我正在编写一个JavaScript函数，该函数发出HTTP请求并返回对结果的承诺（但该问题同样适用于基于回调的实现）。

如果我立即知道为该函数提供的参数无效，该函数应该throw同步还是应该返回被拒绝的Promise（或者，如果您愿意，请使用Error实例调用回调）？

异步功能应始终以异步方式运行（特别是对于错误情况）有多重要？是否确定throw，如果你知道程序是不是一个合适的状态的异步操作继续进行？

例如：

function getUserById(userId, cb) {

  if (userId !== parseInt(userId)) {

    throw new Error('userId is not valid')

  }

  // make async call

}

// OR...

function getUserById(userId, cb) {

  if (userId !== parseInt(userId)) {

    return cb(new Error('userId is not valid'))

  }

  // make async call

}

Answer 1

最终，决定是否同步投掷取决于您，您可能会发现有人在两边争辩。重要的是记录行为并保持行为的一致性。我对此的看法是，您的第二个选择-将错误传递给回调-看起来更优雅。否则，您将得到如下代码：try {    getUserById(7, function (response) {       if (response.isSuccess) {           //Success case       } else {           //Failure case       }    });} catch (error) {    //Other failure case}这里的控制流程有些混乱。似乎if / else if / else在回调中具有单个结构并放弃周围环境会更好try / catch。

Answer 2

异步功能应始终以异步方式运行（特别是对于错误情况）有多重要？非常 重要。是否确定throw，如果你知道程序是不是一个合适的状态的异步操作继续进行？是的，我个人认为这与所有异步产生的错误完全不同，并且需要分别进行处理是可以的。如果某些用户名由于不是数字而被认为是无效的，而某些用户名将在服务器上被拒绝（例如，因为它们已经被使用），则在两种情况下都应进行一次（异步！）回调。如果异步错误仅是由网络问题等引起的，则您可能会以不同的方式发出信号。throw当出现“ 意外 ”错误时，您总是可以的。如果您需要有效的用户标识，则可能会抛出无效的用户标识。如果要预期无效的变量并希望调用者处理它们，则应使用“统一”错误路由，该路由将是异步函数的回调/拒绝承诺。并重复@Timothy：您应该始终记录该行为并保持行为的一致性。

Answer 3

理想情况下，不应抛出回调API，但它们确实会抛出，因为很难避免，因为您必须尝试从字面上捕获所有地方。请记住，throw函数抛出不需要显式抛出错误by 。另一件事是，用户回调也可以很容易地抛出，例如调用JSON.parse而没有try catch。因此，根据以下理想情况，代码的行为如下：readFile("file.json", function(err, val) {    if (err) {        console.error("unable to read file");    }    else {        try {            val = JSON.parse(val);            console.log(val.success);        }        catch(e) {            console.error("invalid json in file");        }    }});必须使用两种不同的错误处理机制确实很不方便，因此，如果您不希望程序成为一堆脆弱的卡片（不编写任何try catch），则应使用将所有异常处理统一在一个机制下的promise ：readFile("file.json").then(JSON.parse).then(function(val) {    console.log(val.success);}).catch(SyntaxError, function(e) {    console.error("invalid json in file");}).catch(function(e){    console.error("unable to read file")})