如何在Express4.x中愉快地使用async的方法

程序员文章站 2022-06-23 12:33:41

前言为了能够更好地处理异步流程，一般开发者会选择 async 语法。在 express 框架中可以直接利用 async 来声明中间件方法，但是对于该中间件的错误，无法通过错误捕获中间件来劫持到。错误处...

前言

为了能够更好地处理异步流程，一般开发者会选择 async 语法。在 express 框架中可以直接利用 async 来声明中间件方法，但是对于该中间件的错误，无法通过错误捕获中间件来劫持到。

错误处理中间件

以上述代码为例，中间件方法并没有通过 async 语法来声明，如果 dosomething 方法内部抛出异常，那么就可以在错误处理中间件中捕获到错误，从而进行相应地异常处理。

而采用 async 语法来声明中间件时，一旦 dosomething 内部抛出异常，则错误处理中间件无法捕获到。

虽然可以利用 process 监听 unhandledrejection 事件来捕获，但是无法正确地处理后续流程。

try/catch

对于 async 声明的函数，可以通过 try/catch 来捕获其内部的错误，再使用 next 函数将错误递交给错误处理中间件，即可处理该场景：

「这种写法简单易懂，但是满屏的 try/catch 语法，会显得非常繁琐且不优雅。」

高阶函数

对于基础扎实的开发来说，都知道 async 函数最终返回一个 promise 对象，而对于 promsie 对象应该利用其提供的 catch 方法来捕获异常。

那么在将 async 语法声明的中间件方法传入 use 之前，需要包裹一层 promise 函数的异常处理逻辑，这时就需要利用高阶函数来完成这样的操作。

相比较第一种方法，「 高阶函数减少了冗余代码，在一定程度上提高了代码的可读性。 」

上述两种方案基于扎实的 javascript 基础以及 express 框架的熟练使用，接下来从源码的角度思考合适的解决方案。

中间件机制

express 中主要包含三种中间件：

应用级别中间件通过 app.use 方法注册，「 其本质上也是调用路由对象上的中间件注册方法，只不过其默认路由为 '/' 」。

中间件的所有注册方式最终会调用上述代码，根据 path 和中间件处理函数生成 layer 实例，再通过栈来维护这些 layer 实例。

express 内部通过 handle 方法来处理中间件执行逻辑，其利用「 闭包的特性 」缓存 idx 来记录当前遍历的状态。

该方法内部又实现了 next 方法来匹配当前需要执行的中间件，从遍历的代码可以明白「 中间件注册的顺序是非常重要的 」。

如果该流程存在异常，则调用 layer 实例的 handle.error 方法，这里仍然是「 遵循了 node.js 错误优先的设计理念 」：

「内部通过判断函数的形参个数过滤掉非错误处理中间件」。
如果 next 函数内部没有异常情况，则调用 layer 实例的 handle_request 方法：

「 handle 方法初始化执行了一次 next 方法，但是该方法每次调用最多只能匹配一个中间件 」，所以在执行 handle_error 和 handle_request 方法时，会将 next 方法透传给中间件，这样开发者就可以通过手动调用 next 方法的方式来执行接下来的中间件。

从上述中间件的执行流程中可以知晓，「 用户注册的中间件方法在执行的时候都会包裹一层 try/catch，但是 try/catch 无法捕获 async 函数内部的异常，这也就是为什么 express 中无法通过注册错误处理中间件来拦截到 async 语法声明的中间件的异常的原因 」。

修改源码

找到本质原因之后，可以通过修改源码的方法来进行适配：

上述代码在 handle_request 方法内部判断了中间件方法通过 async 语法声明的情况，从而采用 promise 对象的 catch 方法来向下传递异常。

「 这种方式可以减少上层冗余的代码，但是实现该方式，可能需要 fork 一份 express4.x 的源码，然后发布一个修改之后的版本，后续还要跟进官方版本的新特性，相应的维护成本非常高。 」

express5.x 中将 router 部分剥离出了单独的路由库 -- router

aop（面向切面编程）

为了解决上述方案存在的问题，我们可以尝试利用 aop 技术在不修改源码的基础上对已有方法进行增强。

以注册应用级别中间件为例，可以对 app.use 方法进行 aop 增强：

前面源码分析的过程中，app.use 内部是有 this 调用的，所以这里需要「 利用 bind 方法来避免后续调用过程中 this 指向出现问题。 」

然后就是利用 aop 的核心思想，重写原始的 app.use 方法，通过不同的分支逻辑代理到原始的 app.use 方法上。

「 该方法相比较修改源码的方式，维护成本低。但是缺点也很明显，需要重写所有可以注册中间件的方法，不能够像修改源码那样一步到位。 」

写在最后

本文介绍了 express 中使用 async 语法的四种解决方案：

除了 try/catch 方法性价比比较低，其它三种方法都需要根据实际情况去取舍，举个栗子：

如果你需要写一个 express 中间件提供给各个团队使用，那么修改源码的方式肯定走不通，而 aop 的方式对于你的风险太大，相比较下，第二种方案是最佳的实践方案。

到此这篇关于如何在express4.x中愉快地使用async的方法的文章就介绍到这了,更多相关express4.x使用async内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！