导航
导航

React中的错误处理

由于本文使用了比较通用的redux技术栈,所以本文默认读者对redux和redux的middleware相关的知识已经有足够的了解,所以本文不会就相关领域做展开讨论。

Error handler是一个项目中不得不做的一件事,不论是用户的错误操作还是网络请求发生异常,都需要一个机制来告诉用户 — 这里挂了,你待会再来。

而如果这个东西做的不好的话,就会散落在项目的各个地方,在任何你觉得会发生错误的地方,你都需要提前做好预防,防止未来系统在这里挂掉。如果这样的话,那么你的handler就会极难维护,错误处理的需求一变,你需要翻遍整个项目,去寻找那些散落在各处的“星星”。

Error Middleware With Redux

在项目中我们使用redux的中间件来管理error handling这件事。在redux的store中,我们使用redux提供的applyMiddleware接口将errorMiddleware与其他的middleware组合起来形成一个enhancer,然后在createStore的时候传进去。

错误处理流程

1
2
3
4
5
6
7
8
9
10
11
12
const createErrorMiddleware = (shouldHandleError: (action: AnyAction) => boolean) => {
return ({ dispatch }: MiddlewareAPI) => {
return (next: Dispatch) => {
return (action: AnyAction) => {
if (shouldHandleError(action)) {
// do what you want
}
return next(action);
};
};
};
};

首先由于是middleware,所以会拦截到所有的action,通常并不是所有的action都需要错误处理,所以我们会在一开始时通过shouldHandleError函数来判断这个action是否需要错误处理,不需要的话直接dispatch一个新的action给下游。

如果需要处理的话可以进一步判断这个action是哪一类错误,需要对其做什么处理等等,这一步往往跟业务强相关,不同的项目组会有不同的需求,需要“对症下药”。比较通用的做法是在拿到error message后在页面中将其显示出来,及时给用户一个反馈,告诉用户这时应该怎么做。

过滤

在有一些比较特殊的情况下我们并不想处理某个类型的错误,这时我们也会在shouldHandleError中进行错误action的过滤。通常可以设置一个标志位,当检测到这个标志位的时候就过滤掉这个action,不进行处理。

通知

错误发生之后,我们通常需要告诉用户我们的App发生了什么错误,或者告诉用户下次应该如何避免这样的错误。这时候就需要一个全局范围的通知信息,将错误信息显示出来,我们一般会选择Toast/Snack Bar作为错误信息的容器。

常见错误

比较常见的错误之一就是业务上的错误请求,比如参数错误,用户误操作发送请求等。这时通常后端会在response中塞入一个error message,我们就可以将error message或者设置在前端的一个默认错误信息放入一个错误的action中。当这个action被error middleware捕获到后就可以dispatch一个新的action通知用户发生了什么错误。

而其它的常见错误比如后端返回的各种状态码4XX/5XX等也会用相同的处理方式进行处理。

主动抛错

在一些情况下前端也需要主动抛出错误,告诉用户当前操作是违规操作,在不发请求的情况下主动抛出错误,提升用户体验。举个例子,比如在文件上传的时候,为了保护磁盘空间,往往会限制用户上传文件的大小。如果此时让后端来返回错误的话,其实文件已经上传了,实属没有必要,所以往往我们会在上传前检查文件大小,如果文件过大,我们便可以主动抛错,告诉用户从新上传一个小一些的文件。