📒【异步】3. 异步方案之回调的不完美

异步进化史

异步在实现上，依赖一些特殊的语法规则。从整体上来说，异步方案经历了如下的四个进化阶段：

回调函数 —> Promise —> Generator —> async/await

其中 Promise、Generator 和 async/await 都是在 ES2015 之后，慢慢发展起来的、具有一定颠覆性的新异步方案。相较于 “回调函数 “时期的刀耕火种而言，具有划时代的意义。

“回调函数”时期存在的问题

回调嵌套 -> 理解问题，缺乏顺序性
场景：根据第一个网络请求的结果，再去执行第二个网络请求；然后根据第二个网络请求的结果执行第三个网络请求... 于是出现了如下的代码，臭名昭著的“回调地狱”现身。

请求1(function(请求结果1){
    请求2(function(请求结果2){
        请求3(function(请求结果3){
            请求4(function(请求结果4){
                请求5(function(请求结果5){
                    请求6(function(请求结果3){
                        ...
                    })
                })
            })
        })
    })
})

这种嵌套的书写方式，排查问题时我们需要绕过很多障眼法，不断的在函数间跳转，甚至需要花费一些时间去思考真正的执行顺序。嵌套和缩进只是回调地狱的一个梗，它导致的问题远不止嵌套导致的可读性降低。
大脑对于事情的计划方式时线性的、阻塞的、单线程的语义，但是回调表达异步流程的方式是非线性的、非顺序的，这使得正确推导这样的代码难度很大。难以理解的代码是坏代码，会导致坏bug。回调地狱带来的负作用有以下几点：

代码臃肿
可读性差
耦合度过高，可维护性差
代码复用性差
容易滋生bug
只能再回调里处理异常

我们需要一种更同步、更顺序、更阻塞的方式来表达异步，就像我们的大脑一样。

控制反转 -> 信任问题
A和B发生于现在，在JavaScript主程序的直接控制之下，而C会延迟到将来发生，并且是在第三方的控制下（多数情况下，是某个第三方提供的工具）。这种控制的转移通常不会给程序带来很多问题。
我们用回调函数来封装程序中的continuation，然后把回调交给第三方（甚至可能是外部代码），接着期待其能够调用回调，实现正确的功能。这种称为 控制反转 ，就是把自己程序一部分的执行控制交给某个第三方。第三方提供某个工具，你传入回调处理自己的逻辑，由于你的代码和第三方工具之间没有一份明确表达的契约，他们调用你的回调时可能出现一些情况：

调用回调过早
调用回调过晚（或者没有调用）
调用回调的次数太少或太多
没有把所需的环境/参数成功传给你的回调函数
吞掉可能出现的错误或异常

// A
ajax("..", function(){
  // C
});
// B

对于被传给你无法信任的工具的每个问题，你都将不得不创建大量的混乱逻辑，此时是否更加明白回调地狱是多像地狱了吧！
回调最大的问题是控制反转，它会导致信任链的完全断裂！

回调的变体

回调设计存在几个变体，意在解决前面讨论的一些信任问题（不是全部！）

分离回调

为了更优雅地处理错误，有些API设计提供了 分离回调（一个用于成功通知，一个用于出错通知）

function success(data){
  console.log(data);
}
function failure(err){
  console.error(err);
}
ajax("http://some.url.1", success, failure);

这种设计，API的出错处理函数 failure() 常常是可选的，如果没有提供的话，就是假定这个错误可以吞掉。ES6 Promise API使用的就是这种分离回调设计。

error-first

error-first风格 回调模式，也称Node风格，因为几乎所有Node.js API都采用这种风格。
其中回调的第一个参数保留用作错误对象。如果成功的话，这个参数就会被清空/置假（后续的参数就是成功数据）。如果产生了错误结果，第一个参数就会被置起/置真（通常就不会再传递其他结果）。

function response(err, data){
  if(err){
    console.error(err)
  }else{
    console.log(data)
  }
}
ajax("http://some.url.1", response);

存在问题

这并没有像表面看上去那样真正解决主要的信任问题，并没有涉及阻止或过滤不想要的重复调用回调的问题。现在事情更糟糕，因为现在你可能同时得到成功或失败的结果，或者都没有，并且你还不得不编码处理这些情况。
尽管这是可采用的标准模式，但更加冗长和模式化，可复用性不高，还得给应用中的每个回调添加这样的代码。
🤔️ 如何解决完全不调用的信任问题？设置一个超时来取消事件
🤔️ 如何解决调用过早的信任问题？永远要异步，创建一个类似于验证概念版本的asyncify()工具

虽然可以写一些特点逻辑来解决这些信任问题，但其难度高于应有的水平，可能会产生更笨重、更难维护的代码，并且缺少足够的保护，其中的损害要直到你受到bug的影响才会被发现。
我们需要一个通用的方案来解决这些信任问题。不管我们创建多少回调，这一方案都应可以复用，且没有重复代码的开销。

异常处理

try…catch是同步代码，只能捕获“同步代码”中的"运行时异常"，"同步代码"是无法获取如setTimeout、Promise等异步代码的异常。

Q：为什么 try...catch 无法直接捕获异步的错误？
比如执行 fs.readdir 的时候，其实是将回调函数加入任务队列中，代码继续执行，直至主线程完成后，才会从任务队列中选择已完成的任务，并将其加入栈中，此时栈中只有这一个执行上下文，如果回调报错，也无法获取调用该异步操作时的栈中的信息，不容易判定哪里出现了错误。

因此，要处理 setTimeout 等回调内部的异常，只能将 try-catch 放置到回调内部。