用 try ... catch 做流程控制真的好吗
用了 async/await 好像必须用 try … catch 做流程控制了？
4 回复
UI 编程里try catch是很实用的，因为UI渲染是单线程的，要渲染多个模块时，假设没有try catch，如
renderModuleA() renderModuleB() renderModuleC()
如果各模块不管好自己的执行上下文，那么自己挂了也会误了别的模块。而很多时候容错处理是很繁冗的，而try catch就提供了一种比较粗放，成本也比较低的错误处理方式，如果觉得一段代码有各种edge case或者异常情况，就用try catch包起来，catch住错误写日志，调度UI现实等等，是程序健壮性非常重要的一环。
所以try catch不应该被看成一种不得不用的东西，而是很有用的东西。
- try/catch 比 error-check 方便, 类似 node 回调第一个参数, 你必须每次都去检查 err, 而 try/catch, 可以只处理你想处理的, 不想处理的直接 throw, 到最上层没人处理, 导致 fatal 异常
- try/catch 比 painc/recover 更清楚, golang 的 recover 必须写在可能导致 panic 代码前面, 已经 panic, 再 defer recover 没有用
node 终于可以 try/catch 了, 真好…
try-catch 好像性能是要差一点的，不宜到处都用。我倾向于最小化使用它。Async/await 背后是 promise。如果是自己写的，可以把 error 也 resolve，比如{ok: -1}，这样在调用时就不需要 try-catch，而是判断 return 结果。如果是调用的，那该用就用。 自豪地采用 CNodeJS ionic
