CN113609012B - 规范化处理后端异常报错的方法及系统 - Google Patents

Abstract

本发明提出了一种规范化处理后端异常报错的方法及系统，其中方法包括：步骤一、通过预设封装模块接收抛出的异常；步骤二、异常过滤器捕获抛出的异常并进行封装，抛出固定格式的错误信息；步骤三、所述预设封装模块针对参数类型对所述异常进行分别处理和再次封装；步骤四、将最终封装后的错误反馈至前端开发人员，以便于开发人员对错误的处理。本发明通过统一异常抛出的信息格式，实现规范化字符串信息进行切割及重新封装的一致性过程，同时使得异常信息更易于理解。

Description

规范化处理后端异常报错的方法及系统

技术领域

本发明涉及一种规范化处理后端异常报错的方法及系统，特别是涉及计算机网络应用程序开发的技术领域。

背景技术

目前，现有的web应用普遍流行使用前后端分离的开发技术，即前后端同时进行开发，此种开发模式使前后端能够并发的进行工作，加快项目的诞生。

开发过程中，现阶段网页后端的校验多为框架自带的校验模块直接抛出的异常信息，这些异常信息为dto(Data Transfer Object，即数据传输对象)校验器直接抛出的错误，并在框架捕获到校验器抛出的错误后，将其返回给客户端。当通过了第一层校验后，数据就会传入业务逻辑层，业务逻辑层为编码人员自己实现的业务逻辑，同时捕获其中产生的错误，但抛出的错误大多也为自定义的错误，不具备规范化。最后在数据持久化过程中，持久层框架或者数据库都可能抛出错误，然后向前端返回报错的信息。这些错误都没有经过规范化的定义，各自有各自的格式。

不规范的报错方式往往呈现以下缺陷：首先，前端需要自己实现前端的校验，后端也需要对客户端通过HTTP传递的参数进行校验。因为对后端来说校验是必须要做的，而前端没有办法校验业务逻辑，所以前端没有办法实现完全的校验，因此，前端实现的校验从一定程度上来说便会占据开发过程中的资源，从而造成开发中的浪费。

其次，web框架对于后端的校验以及各种报错信息没有封装，来自dto层校验器的报错与来自dao(Data Access Object)层的报错信息结构不统一，同时在业务逻辑层编码人员根据自己风格编写抛出的异常信息，导致前端接收后端的报错信息后只能在表单某侧对报错信息进行展示或者罗列，进一步导致用户看到提示的报错信息时，无法判断问题在哪里，影响用户的使用体验。更为严重的问题是，由于后端的各个模块报错信息的不一致，当后端出现问题时对问题的定位和追踪也比较麻烦，首先得判断这个错误信息的来源，然后才能判断问题发生的原因。

发明内容

发明目的：提出一种规范化处理后端异常报错的方法，以解决现有技术存在的上述问题。

技术方案：第一方面，提出了一种规范化处理后端异常报错的方法，该方法具体包括以下步骤：

步骤一、通过预设封装模块接收抛出的异常；

步骤二、异常过滤器捕获抛出的异常并进行封装，抛出固定格式的错误信息；

步骤三、所述预设封装模块针对参数类型对所述异常进行分别处理和再次封装；

步骤四、将最终封装后的错误反馈至前端开发人员，以便于开发人员对错误的处理。

在第一方面的一些可实现方式中，步骤一中抛出的异常信息采用统一信息格式进新格式规范；所述统一信息格式为“模块--属性__错误信息”。通过“--”与“__”分割错误信息，进行字符串分割，获取对应的信息报错内容。

所述预设封装模块向外公开一个交互函数，所述交互函数中包含一个定义错误发生模块名称的参数moduleName，交互函数根据接收到的参数类型对传入的报错内容分别进行处理，并将错误信息转化为“模块--属性__错误信息”格式的字符串，随后，创建Error对象，并将该字符串添加到Error对象中返回给交互函数的调用方。

在第一方面的一些可实现方式中，所述步骤二进一步为：采用异常过滤器捕获抛出的异常，对其进行封装，并抛出固定格式的错误信息。

所述异常过滤器预设为一个函数，该函数用于接收一个错误对象参数，或一个错误对象的列表参数。

所述异常过滤器接收到抛出异常的参数后，根据错误的来源对其分别处理，如果是dto层的接口参数校验错误，则现将异常信息转化为对应结构的对象，然后向前端抛出，供前端开发人员使用。

如果是业务逻辑层或者持久层抛出的错误，则首先将其转化为对应结构的对象，然后判断该错误是否可以暴露给前端，并进行日志记录。

在第一方面的一些可实现方式中，在客户端与后台服务端进行错误信息交互时，在步骤一前还包括客户端向后台服务端发送数据请求，以及后台服务端的响应判断。

当后台服务端的响应判断结果为没有产生异常时，反馈成功响应至客户端；反之，后台服务端产生异常，向异常处理器抛出异常数据，并进行步骤一以下剩余步骤。

第二方面，提出一种规范化处理后端异常报错的系统，该系统具体包括：

用于接收抛出的异常第一模块；

用于对抛出的异常进行封装的第二模块；

用于根据参数类型对抛出的异常进行分别处理和再次封装的第三模块；

用于反馈错误信息的第四模块。

在第二方面的一些可实现方式中，所述第一模块接收来自后台服务端产生的异常错误信息；所述第二模块通过预设的异常过滤器捕获抛出的异常并进行封装，抛出固定格式的错误信息；所述第三模块采用预设封装模块针对参数类型对所述异常进行分别处理和再次封装；所述第四模块将最终封装后的错误反馈至前端开发人员，以便于开发人员对错误的处理。

客户端与后台服务端之间的交互过程进一步为：

首先，客户端向后台服务端发送数据请求；其次，后台服务端根据产生的结果反馈响应数据至客户端；当后台服务端没有产生异常时，反馈成功响应至客户端；反之，后台服务端产生异常，并向异常处理器抛出异常数据；再次，异常处理器对接收到的异常数据进行处理，并通过制定的规范对错误信息进行格式化处理；最后，将处理后的错误信息反馈至客户端。

有益效果：本发明提出了一种规范化处理后端异常报错的方法及系统，通过统一异常抛出的信息格式，实现规范化字符串信息进行切割及重新封装的一致性过程，同时使得异常信息更易于理解。本申请提出的技术方案打通了前后端校验的壁垒，避免了前后端在表单校验实现不一致导致用户无法判断真正错误原因的问题。通过将校验错误通过本文的方法封装后，后端抛出的错误格式可以直接被前端遍历，并设置到表单对应的项中展示，使得用户能够迅速知道错误的字段以及错误的原因。

另一方面，将所有的异常统一封装处理，使得前端可以快速识别异常的类型以及具体的原因，避免前端无法识别后端抛出的异常或者后端直接抛出“服务器异常”这种比较模糊、难以定位的信息，并对运维和问题追踪有一定帮助。前端将表单校验部分任务完全交给后端处理，前端只需实现相应的视图渲染逻辑，以及前端不需要对后端抛出的错误进行整合和处理，只需要在后端返回的结果中读取相应的错误信息，减少了前端开发的工作量，提升了开发效率。

附图说明

图1为本发明的数据处理流程图。

图2为本发明实施例客户端与后台服务端交互流程示意图。

图3为本发明实施例使用nestjs的后端整体架构示意图。

具体实施方式

在下文的描述中，给出了大量具体的细节以便提供对本发明更为彻底的理解。然而，对于本领域技术人员而言显而易见的是，本发明可以无需一个或多个这些细节而得以实施。在其他的例子中，为了避免与本发明发生混淆，对于本领域公知的一些技术特征未进行描述。

申请人认为现价段开发过程中，造成报错信息处理繁琐、不一致的原因如下：

(1)现阶段前后端分离开发的大环境下，前后端的开发人员以及技术都是不同的，没有人对前后端的校验进行统一和规范。

(2)后端开发人员只注重于实现后端的业务逻辑，而校验问题最终是暴露给界面的用户的，所以后端开发人员并不重视后端的报错信息的规范化，也不清楚前端开发人员需要什么结构的数据。

(3)后端异常抛出是多样化的，可能是dto层报错，也可能是服务中业务逻辑处理时报错，也可能是持久化时在dao层发生错误，也可能是引用的库抛出的报错信息，也可能是编码人员自己抛出的异常。这就导致了后端报错信息的规范化更加难以处理，尤其在没有完全打通后端和持久层的类型安全的系统中。

(4)后端也可以针对每个字段创建校验接口，对前端提供的表单数据做校验处理，但是实现复杂，维护困难，前端请求数量增加的同时也增加了服务的负担。

(5)在微服务架构盛行的现在，各个后端之间的报错信息业务要做统一处理，否则问题定位十分麻烦。

实施例一

在一个实施例中，提出一种规范化处理后端异常报错的方法，通过统一异常抛出的信息格式，实现规范化字符串信息进行切割及重新封装的一致性过程，如图1所示，该方法具体包括以下步骤：

步骤一、通过预设封装模块接收抛出的异常；

步骤二、异常过滤器捕获抛出的异常并进行封装，抛出固定格式的错误信息；

步骤三、所述预设封装模块针对参数类型对所述异常进行分别处理和再次封装；

步骤四、将最终封装后的错误反馈至前端开发人员，以便于开发人员对错误的处理。

本实施例通过统一后端报错方式，不仅为前端展示提供了方便，也为后端问题追踪提供了查询的依据。

实施例二

在实施例一基础上的进一步实施例中，针对JS开发过程中抛出的错误信息，由于其错误对象Error中仅有字符串信息，所以为了更好的适配报错信息的规范，提出同一的信息错误报错格式。优选实施例中，将报错格式预定义为“模块—属性__错误信息”，当dto层校验username字段时，若出现错误信息报错，则报错为“dto—username__用户名必须为字符串！”。这个格式作为后端错误信息的基本模板，所有模块向filter过滤器抛出的异常必须经过该模板的封装。模板首先通过“--”与“__”分割错误信息，使得处理该信息的模块能够轻松通过字符串分割得到相应的内容。通过统一的报错格式，可以便于后端通用过滤器模块对字符串信息进行切割及重新封装。

实施例三

在实施例一基础上的进一步实施例中，为了方便开发者对错误信息的读取和处理，在报出的错误信息中，采用封装模块对所有层面抛出的异常进行统一管理和封装。

具体的，本实例中提出的封装模块向外公开一个交互函数，该交互函数中包含一个定义错误发生模块名称的参数moduleName，交互函数根据接收到的参数类型对传入的报错内容分别进行处理，并将错误信息转化为“模块—属性__错误信息”格式的字符串，随后，创建Error对象，并将该字符串添加到Error对象中返回给函数的调用方。优选实施例中，交互函数接收到的参数类型包括：dto、service、dao、other。

在进一步的实施例中，由于实际应用过程中，对于不同的模块使用的方式不同，因此，采用不同的应对措施进行参数校验。优选实施例中，采用class-validator对HTTP请求参数进行校验，在装饰器函数的“validationOptions”参数中传递message字段，该字段经由错误处理模块处理。对于service层，我们在开发中将service层封装为业务逻辑service(domain service)和持久层service(database service)两部分，持久层service只进行数据库的CRUD基础任务或是数据库事务。创建不同的service文件，对两个不同种类的service挂载不同的错误处理方法，其中，业务逻辑层挂载service方法，持久层挂载dao方法。从而使得系统中所有模块的异常信息都采用“模块—属性__错误信息”格式的字符串模板进行错误信息统一规范化的封装，并抛出到过滤器中。

实施例四

在实施例一基础上的进一步实施例中，为了更好的适配开发人员对报错信息的读取和认知，采用异常过滤器捕获抛出的异常，并对其进行封装，从而抛出固定格式的错误信息。

具体的，本事实例中采用的异常过滤器定义为一个函数，该函数用于接收一个错误对象参数，或一个错误对象的列表参数。在基于Nestjs的后端开发过程中，利用Nestjs对异常过滤器进行了封装，并提供了一个ExceptionFilter异常过滤器接口类，在实现这个类时，使用有效签名提供catch(exception:T,host:ArgumentsHost)方法。ExceptionFilter异常过滤器接口类可以提供一个@Catch装饰器来告知装饰器捕获哪一种或者哪些异常。

为了实现针对性的错误信息捕捉，首先预设一种异常类UnifiedException，然后在过滤器上的@Catch装饰器的参数中提供预设的异常类，从而使得该过滤器能够只捕获预定抛出的UnifiedException异常。

异常过滤器接收参数后，函数根据错误的来源对其分别处理，如果是dto层的接口参数校验错误，则现将异常信息转化为上述结构的对象，然后向前端抛出，供前端开发人员使用。

如果是业务逻辑层或者持久层抛出的错误，则首先将其转化为上述结构的对象，然后判断该错误是否可以暴露给前端，并进行日志记录。

在原有的class-validator中，返回的错误信息为单纯的字符串数组。

例如：

“errors”:[

‘用户名长度不能超过20’,

‘密码必须大于6位’,

‘昵称已存在’,

]

这种错误格式虽然便于理解和罗列，但前端无法将每一条错误信息对应到表单相应的项中。将校验错误通过本文的方法封装后，后端抛出的错误格式可以直接被前端遍历，并设置到表单对应的项中展示，使得用户能够迅速知道错误的字段以及错误的原因。

本实施例采用异常过滤器接收系统各个模块中抛出的异常后，对异常信息进行封装，抛出固定格式的错误信息，该格式不仅可以作为日志存储的信息，而且由于该报错信息完整地携带了键值“key”以及错误内容，所以可以直接将其抛出给前端，前端开发人员可以根据错误信息将其直接展示在预设表单的具体项中。具体的，封装的对象数据格式如下表所示：

对于错误列表errors类，结构如下：

名称	属性	类型
			键名	key	string
错误信息列表	errorsList	array

对于错误信息列表errorsList类，架构如下：

名称	属性	类型
			错误信息项	无	string

实施例五

在实施例一基础上的进一步实施例中，采用vue.js作为前端的框架，使用vuetify作为UI层框架，由于vuetify的“v-input”作为一个可校验的组件，组件可以自定义错误状态，并且提供了error-message属性传入错误信息，error-message可以是字符串也可以是数组，在实际工况中更贴合后端对前端的校验。前端开发者只需要读取请求接口返回的规范化错误信息，将对应的键值设置到相应v-input组件的error-message属性中，即可实现前后端的统一校验，后端无需针对每个字段开启校验接口，前端也不需要对表单组件编写详细的校验方法，十分方便又实用。

后端实现了错误的规范化处理后，前端可以无需实现具体的校验规则，只需要实现表单的结构，以及向后端提交的接口，表单中所有字段的详细错误信息都可以从后端接口返回的数据中获得，当用户填写完某个表单后，点击并在界面上进行展示，大大提升了前端开发者开发的效率。

实施例六

在一个实施例中，提出一种规范化处理后端异常报错的系统，用于实现实施例一中所提出的规范化处理后端异常报错的方法，该系统具体包括：

用于接收抛出的异常第一模块；

用于对抛出的异常进行封装的第二模块；

用于根据参数类型对抛出的异常进行分别处理和再次封装的第三模块；

用于反馈错误信息的第四模块。

在进一步的实施例中，所述第一模块接收来自后台服务端产生的异常错误信息；所述第二模块通过预设的异常过滤器捕获抛出的异常并进行封装，抛出固定格式的错误信息；所述第三模块采用预设封装模块针对参数类型对所述异常进行分别处理和再次封装；所述第四模块将最终封装后的错误反馈至前端开发人员，以便于开发人员对错误的处理。

如图2所示，客户端与后台服务端之间的交互过程进一步为：首先，客户端向后台服务端发送数据请求；其次，后台服务端根据产生的结果反馈响应数据至客户端；当后台服务端没有产生异常时，反馈成功响应至客户端；反之，后台服务端产生异常，并向异常处理器抛出异常数据；再次，异常处理器对接收到的异常数据进行处理，并通过制定的规范对错误信息进行格式化处理；最后，将处理后的错误信息反馈至客户端。

实施例七

在实施例一基础上的进一步实施例中，如图3所示，使用nestjs的后端整体架构，前端发起的请求被路由拦截，首先会经过认证模块(authentication)的验证，通过后请求到达dto层，使用class-validator对请求的参数进行校验，如果校验通过则进入controller层，从头controller调用服务层(service)的服务，读取持久层的数据进行处理然后返回给用户。

从该图中可见，无论是class-validator报错，还是controller层的报错，还是service层的报错，都会经过error-handler的封装，然后向filter抛出UnifiedException类错误，最终被filter捕获及处理，最终实现了后端报错信息的一致性。

本申请打通了前后端校验的壁垒，避免了前后端在表单校验实现不一致导致用户无法判断真正错误原因的问题。如前后端对0-20这个范围的校验规则不同，前端认为0合法，但服务端认为其不合法，就出现了前后端校验实现不一致导致的校验冲突问题。所有的异常统一封装处理，使得前端总是能够识别异常的类型以及具体的原因，避免前端无法识别后端抛出的异常或者后端直接抛出“服务器异常”这种比较模糊、难以定位的信息，并对运维和问题追踪有一定帮助。

另一方面，本申请提出的规范化管理使得异常信息更易于理解，例如实际工况中出现如“dto—username__用户名必须为字符串！”的异常信息时，可以瞬时判断出是请求参数的username字段抛出异常，异常原因为提交的username不是合法的字符串值。

本发明提出的实现后端报错一致性的技术方案，通过前端将表单校验部分任务完全交给后端处理，使得前端只需实现相应的视图渲染逻辑，前端不需要对后端抛出的错误进行整合和处理，只需要在后端返回的结果中读取相应的错误信息即可，减少了前端开发的工作量，提升了开发效率。

如上所述，尽管参照特定的优选实施例已经表示和表述了本发明，但其不得解释为对本发明自身的限制。在不脱离所附权利要求定义的本发明的精神和范围前提下，可对其在形式上和细节上做出各种变化。

Claims (7)

1.一种规范化处理后端异常报错的方法，其特征在于，具体包括以下步骤：

步骤一、通过预设封装模块接收后端抛出的异常，所述异常都采用“模块—属性__错误信息”格式的字符串模板进行错误信息统一规范化的封装，并抛出到过滤器中；

步骤二、采用异常过滤器捕获预设封装模块抛出的异常，对其进行封装，并抛出固定格式的错误信息，所述固定格式的错误信息用于作为日志存储的信息，同时完整地携带了键值“key”以及错误内容，能够直接将其抛出给前端，前端开发人员可以根据错误信息将其直接展示在预设表单的具体项中；

步骤三、所述异常过滤器针对参数类型对所述预设封装模块抛出的异常进行分别处理和再次封装；所述异常过滤器预设为一个函数，该函数用于接收一个错误对象参数，或一个错误对象的列表参数；

所述异常过滤器接收到抛出异常的参数后，根据错误的来源对其分别处理，当错误类型是dto层的接口参数校验错误，则现将异常信息转化为对应结构的对象，然后向前端抛出，供前端开发人员使用；

当错误类型是业务逻辑层或者持久层抛出的错误，则首先将其转化为对应结构的对象，然后判断该错误是否暴露给前端，并进行日志记录；

步骤四、将最终封装后的错误反馈至前端开发人员，以便于开发人员对错误的处理。

2.根据权利要求1所述的一种规范化处理后端异常报错的方法，其特征在于，步骤一中所述预设封装模块在封装异常数据时，通过“—”与“__”分割错误信息，进行字符串分割，获取对应的信息报错内容。

3.根据权利要求1所述的一种规范化处理后端异常报错的方法，其特征在于，

为了便于开发者对错误信息的读取和处理，在报出的错误信息中，所述预设封装模块执行封装的过程中，向外公开一个交互函数，所述交互函数中包含一个定义错误发生模块名称的参数moduleName，交互函数根据接收到的参数类型对传入的报错内容分别进行处理，并将错误信息转化为“模块—属性__错误信息”格式的字符串，随后，创建Error对象，并将该字符串添加到Error对象中返回给交互函数的调用方。

4.根据权利要求1所述的一种规范化处理后端异常报错的方法，其特征在于，在客户端与后台服务端进行错误信息交互时，在步骤一前还包括客户端向后台服务端发送数据请求，以及后台服务端的响应判断。

5.根据权利要求4所述的一种规范化处理后端异常报错的方法，其特征在于，

当后台服务端的响应判断结果为没有产生异常时，反馈成功响应至客户端；反之，后台服务端产生异常，向异常处理器抛出异常数据，并进行步骤一以下剩余步骤。

6.一种规范化处理后端异常报错的系统，其特征在于，具体包括：

用于接收抛出的异常第一模块；

用于对抛出的异常进行封装的第二模块；

用于根据参数类型对抛出的异常进行分别处理和再次封装的第三模块；

用于反馈错误信息的第四模块；

所述第一模块通过预设封装模块接收来自后台服务端产生的异常错误信息，并对异常采用“模块—属性__错误信息”格式的字符串模板进行错误信息统一规范化的封装，并抛出到过滤器中；

所述第二模块采用异常过滤器捕获预设封装模块抛出的异常，对其进行封装，并抛出固定格式的错误信息，所述固定格式的错误信息用于作为日志存储的信息，同时完整地携带了键值“key”以及错误内容，能够直接将其抛出给前端，前端开发人员可以根据错误信息将其直接展示在预设表单的具体项中；

所述第三模块执行数据处理过程跟中，所述异常过滤器针对参数类型对所述预设封装模块抛出的异常进行分别处理和再次封装；所述异常过滤器预设为一个函数，该函数用于接收一个错误对象参数，或一个错误对象的列表参数；

所述异常过滤器接收到抛出异常的参数后，根据错误的来源对其分别处理，当错误类型是dto层的接口参数校验错误，则现将异常信息转化为对应结构的对象，然后向前端抛出，供前端开发人员使用；

当错误类型是业务逻辑层或者持久层抛出的错误，则首先将其转化为对应结构的对象，然后判断该错误是否暴露给前端，并进行日志记录；

所述第四模块将最终封装后的错误反馈至前端开发人员，以便于开发人员对错误的处理。

7.根据权利要求6所述的一种规范化处理后端异常报错的系统，其特征在于，客户端与后台服务端之间的交互过程进一步为：

首先，客户端向后台服务端发送数据请求；其次，后台服务端根据产生的结果反馈响应数据至客户端；当后台服务端没有产生异常时，反馈成功响应至客户端；反之，后台服务端产生异常，并向异常处理器抛出异常数据；再次，异常处理器对接收到的异常数据进行处理，并通过制定的规范对错误信息进行格式化处理；最后，将处理后的错误信息反馈至客户端。