1回答

沁尘

2022-04-10

已采纳

这个问题问得很好。

这个其实是程序设计的问题。在软件工程中，没有完美的解决方案，async/await 也是如此。

async/await 这个语法糖在业务开发中，唯一一个可能最会让人不适的一点就是关于异常处理的问题，因为他确实没有类似 .catch 的语法。在使用了async/await 语法之后，我们想处理可能存在的异常就只有使用 try/catch 这种处理方式，这种处理方式在绝大数业务功能开发的场景下都是没有问题的。因为在业务开发这种场景下，绝大多数产生的异常都是没办法怎么处理的，或者说不需要处理，我们可以让它继续向上抛，或者在 catch语句块里面集中处理掉。所以 async/await 有没有类似 .catch 的处理机制就显得不是那么的重要了，但有种场景是例外：

async run(){
   try{
        await funcA()
        await funcB()
        await funcC()
    }catch(e){
        console.log(e)
    }
}

比如这里我们调用了一个存在 3 个使用了 await 关键字修饰了的异步函数，同时里面都产生了异常，那么假如我们需要针对不同函数产生的异常进行差异化处理的话，这时候就麻烦了，因为区分不了。

这种代码逻辑一般出现在一些开源或者底层类库而不是业务功能里。在很多类库的源码实现里，如果涉及异步的话，清一色都是使用 promise 的各种 API 而不是使用 async/await，这里并不是async/await不好，而是它不擅长处理这种场景问题。所以在课程中，我提醒过同学们，虽然 async/await 很好，但是依然还是需要学习回调函数和 promise，这里除了出于基本功的考虑以外，还有一点就是在某些场景下，它们之间是没有互相可替代性的，该用回调函数还是得用，该用 promise也一样。只不过对于业务功能开发这种场景来说，async/await是我们处理异步调用的优先选择而已。

0

2

沁尘

回复

精慕门0241520

感谢同学的认可。的确，我们平时在使用各种应用的时候，你看到的那些很模糊的提示基本上 99%都是 catch 统一处理的，因为没办法怎么针对性处理，此时能做的就是记录下日志而已，然后事后尝试修复问题。不过这里还要补充说明一点就是，异常其实是一个语言无关的软件设计，这里面是蕴含软件工程设计思想的。一个异常要不要处理，怎么处理，什么时候处理都是有讲究的；另外，我们作为软件的开发者，还会主动地让程序出现异常，这是一种控制代码执行逻辑的技巧，在后续的课程章节中会有这块的应用，同学可以自行体会。

2022-04-10

共2条回复