一个很好的ES2017 async/await模式是:
能够处理这样的错误真的很好。但是,假设我想异步获取一个值,我想保护它免受重新分配(例如:数据库会话)的影响,但我仍然想使用async/await模式(纯粹是因为我认为它更直观)。
以下代码将无法工作,因为const是块级作用域:
当然,你可以在
显然,简单的答案是不要在这里使用这种模式。改用Promises和回调函数。或者使用
[问题]: 有没有一种方法可以将await/async try/catch块包装到每个函数中? 这似乎是一个潜在的解决方案,但不如
理想情况下,您可能想要执行类似于
更新: 如@jmar777下面建议的另一种选择:
这可能是我在实践中找到的与上述两个示例最接近的方法。但它会打破上述示例中阻止下游执行的“return”范围。这是一种不错的类同步处理方式。
每个解决方案都有其权衡之处。
我已经手动提升了变量,并将其放置在函数块的顶部作为工作解决方案(如jmar777的答案中所述),这仍然是一个有趣的问题,因此我现在将保留该问题。
async function () {
try {
var result = await some_promised_value()
} catch (err) {
console.log(`This block would be processed in
a reject() callback with promise patterns
but this is far more intuitive`)
return false // or something less obtuse
}
result = do_something_to_result(result)
return result;
}
能够处理这样的错误真的很好。但是,假设我想异步获取一个值,我想保护它免受重新分配(例如:数据库会话)的影响,但我仍然想使用async/await模式(纯粹是因为我认为它更直观)。
以下代码将无法工作,因为const是块级作用域:
async function () {
try {
const result = await get_session()
} catch (err) {
console.log(`This block should catch any
instantiation errors.`)
return false
}
// Can't get at result here because it is block scoped.
}
当然,你可以在
try
块中执行函数的其余部分,但这样你会冒着捕获应该在其他地方被忽略的错误的风险。(例如,在编写测试时遇到了这个问题,像测试失败这样的错误需要回退到测试套件,但我想自己处理驱动器实例化。也许我正在落入某种反模式,因为我没有让这些错误回退到测试套件。)显然,简单的答案是不要在这里使用这种模式。改用Promises和回调函数。或者使用
var
并避免块作用域的const
和let
。但对于其他考虑因素,我喜欢重新分配保护和块作用域的好处。[问题]: 有没有一种方法可以将await/async try/catch块包装到每个函数中? 这似乎是一个潜在的解决方案,但不如
try/catch
易读。 try/catch
不会破坏函数作用域,并且我可以在try/catch
块内使用return
,这似乎更符合async/await
的精神,为异步代码带来了更多类似过程逻辑的外观。理想情况下,您可能想要执行类似于
const x = await y() catch (err)
或const x = await y() || fail
的操作,但我无法想到任何具有类似流程的语法上正确的东西。更新: 如@jmar777下面建议的另一种选择:
const x = await y().catch(() => {/*handle errors here*/})
这可能是我在实践中找到的与上述两个示例最接近的方法。但它会打破上述示例中阻止下游执行的“return”范围。这是一种不错的类同步处理方式。
每个解决方案都有其权衡之处。
我已经手动提升了变量,并将其放置在函数块的顶部作为工作解决方案(如jmar777的答案中所述),这仍然是一个有趣的问题,因此我现在将保留该问题。
async
/await
处理拒绝的语法。 - Bergi