希望大家可以收获：

1，背景分析是否贴合工作的实际场景，能否触及痛点；

2，统一的技术方案，并演示最终的实现效果；

3，前端和后端相对完整的技术实现方案，系统的思考方式；

背景和需求

不同人群对错误处理的期望不同：这里基于业务系统简单列表汇总；

下面进行抽象和汇总。

一个合适的错误处理方案应该是怎样的？

统一技术方案

后端

形式： 中间件的方式，定义暴露的配置属性，对异常进行统一的处理封装；

这里做一下调整，统一把分散在微服务里面错误码枚举放到团队公共的SDK中；

后端错误的分类：

内部：主要是对前端，大部分错误通过异常的方式抛出，后端做统一的处理；

外部系统：主要对接外部系统，有些是直接拼接错误码和错误消息的方式输出的；

建立在服务可用，即httpStatus=200的基础上，内部异常的分类：

如果网关服务不可用： nginx需要有对应的40X , 友好json数据

如果网关后面的后端服务不可用： 后端服务需要返回 40X，50X的友好json数据；

查看老业务系统的代码，现在后端的错误处理方式分两种：

老业务系统统一异常处理分类

直接拼接错误码返回

 if (oauth2Authentication.isAuthenticated()) {
            UserModel user = dubboConfigService.getSystemSecurityFacade().getUserByUsername(oauth2Authentication.getName());
            return ResponseResult.builder().errcode(0L).data(user).errmsg("授权用户信息加载成功").build();
        } else {
            return ResponseResult.builder().errcode(10403L).errmsg("未授权").build();
        }

异常的知识补充：

Exception: 可以预见到的异常情况，应该被捕获或者处理，在java中，分为检查异常（编译期）和不检查异常（运行期）。

Error: 出现了错误系统不能正常运行或者恢复，一般情况不容易发生；

共同点：都继承自Throwable，在java中只有Throwable的子类可以被catch或者throw;

ERROR一般是后端服务挂了，一般无法恢复，提示501 服务不可用或者404 ；

Throwable 异常的基类，一般不直接处理；

重点处理的Exception和RuntimeException

在处理异常的时候，有4个基本规则需要注意：

1. 不要catch 最普遍的Exception ，而应该优先捕获具体的异常，可以留下足够的诊断信息；
2. 不要生吞异常，应该尝试抛出或者写到日志，否则无法判断异常发生的位置；
3. 不要使用e.printStackTrace(),在分布式系统中，无法确定输出到了什么位置，应该输出到日志中；
4. 提早抛出，晚点捕获；提高效率

自定义异常的时候需要注意两点：
1，尽量不要定义检查异常
2，异常需要保留足够的诊断信息，但是也需要脱敏；

新业务系统错误码统一管理

1. 按照微服务统一的规范枚举统一管理错误码，错误信息，并填充建议操作信息，可通过共同接口进行规范；

比如design微服务定义微服务级别的错误码枚举 需要实现 ErrorCodeI接口，填充服务名称，错误码，错误提示信息，正确操作指引信息；

public interface ErrorCodeI {
    /**
     * 错误码
     * @return
     */
    String getErrCode();

    /**
     * 错误描述
     * @return
     */
    String getErrDesc();

    /**
     * 获取微服务的名称
     * @return
     */
    default String getServiceName(){
        return null;
    }

    /**
     * 获取恢复错误的正确指导
     * @return
     */
    default String getCorrectGuid(){
        return null;
    }
}

2. 收缩自定义的errcode,errmessage到对应的枚举中，进行统一的编码和错误信息配置；

3. 网关提供接口和前端页面，展示所有的错误码和错误信息，建议处理方法； 作为一个补充的查找建议操作的方案；（可在网关汇聚所有的微服务中的错误码信息，并展示出来）

新业务系统异常体系分级分类

1,输入参数异常（提示给到前端）

2,逻辑业务异常，JVM运行时异常（各微服务按照类别自行扩展）

3,内部异常（中间件的连接错误和异常，进行统一封装）

4, 托底的异常捕获（如果不是以上的异常，直接提示服务器内部错误，并提供可以查错的地方；）

分别配置好对应的errcode, errmsg需要考虑到英文的情况，可对已经发现的中间件异常进行定义前置名称，英文异常信息通过翻译接口解决，最差要做托底中文信息替换；

前端

**原则：
服务端能响应的、能返回错误的，提示语使用后端返回
服务端不能响应的、不能返回错误的，提示语使用前端约定
**1. 状态码一览表

​

2. 后端返回数据格式
   | 字段 | 说明 |
   | — | — |
   | errCode | 错误码 |
   | errMessage | 提示消息 |
   | data | 返回结果 |
   | traceId | skywalking的跟踪ID |

3. 前端实现axios拦截器异常捕获，封装组件实现，展示逻辑&形式

组件文档： 部署到服务器上再统一放开

更多的需求点

日常开发中如何使用

错误码： 如果是系统内部的，即不对外部的第三方系统开发，错误码使用字符串，可读性更好；

如果是对外部的第三方系统的，可使用统一的数字编码，也可使用字符串，根据需要来；

加入你负责一个服务的开发，下面两种场景是你必须要考虑的。

团队公用SDK中定义微服务对应的错误枚举

写法如下：在client包中；

package com.xxx.app.paas.client.exception;

import com.alibaba.cola.dto.ErrorCodeI;
import lombok.AllArgsConstructor;
import lombok.Getter;

/**
 * @author carter
 * create_date  2020/7/7 13:55
 * description     应用级别的错误码统一定义
 */

@AllArgsConstructor
public enum  ConsoleErrorCodeEnum implements ErrorCodeI {

    PARAM_ERR("11010000","参数检查出错","请按照输入提示输入或者选择"),
    BIZ_CREATE_GATEWAY_ERR("11020001","创建网关出错","请检查应用的编码最好只包含字母和数字"),
    BIZ_CREATE_CONFIG_ERR("11020002","创建配置文件出错","请联系运维人员检查应用的配置文件模板在nacos中是否存在"),
    SYS_DATABASE_LINK_ERR("11030001","数据库出错","请联系运维人员检查数据库的连接信息"),
    SYS_NPE_ERR("11030002","空指针错误","请联系开发人员解决问题"),

    //已知异常转换
    DIVISOR_CAN_NOT_BE_ZERO("DIVISOR_CAN_NOT_BE_ZERO","除数不能为0","请联系开发人员检查你的除数是不是0"),

    //安装部署
    INSTALL_ERR_START_PATH("11019000","启动失败，无法获取正确的pid","请输入正确的包文件路径或启动命令有误"),
    INSTALL_ERR_START_FILE("11019001","文件不存在","请确保包文件存在"),
    INSTALL_ERR_SAVE_NS("11019002","相同的命名空间不能安装第二套云枢","请正确选择注册中心的namespace"),
    ;

    private String errorCode;

    private String errorDesc;

    @Getter
    private String correctGuid;




    @Override
    public String getErrCode() {
        return errorCode;
    }

    @Override
    public String getErrDesc() {
        return errorDesc;
    }

    @Override
    public String getServiceName() {
        return "app-paas";
    }


}

如何抛出业务或者系统异常？

统一通过类Exceptions来抛出异常；

com.alibaba.cola.exception.Exceptions

使用实例如下：

package com.xxx.app.paas.controller;

import com.alibaba.cola.exception.Exceptions;
import com.xxx.app.paas.domain.exception.ConsoleErrorCodeEnum;
import org.springframework.util.Assert;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

/**
 * @author carter
 * create_date  2020/7/8 11:19
 * description     错误测试接口
 */
@RestController
public class ErrorCodeControllerI {


    //校验异常
    @GetMapping("/error/check_param")
    public void checkParamException() {
        Assert.isTrue(1 == 2, "xxx参数校验错误");
    }


    //业务异常
    @GetMapping("/error/biz")
    public void bizException() {
        Exceptions.throwBizException(ConsoleErrorCodeEnum.BIZ_CREATE_CONFIG_ERR);
    }

    //系统异常
    @GetMapping("/error/sys")
    public void sysException() {
        String a = null;
        a.getBytes();
    }


    //已经识别的系统异常，可以给特定的错误提示和错误码
    @GetMapping("/error/sys2")
    public void sys2Exception() {
        try {
            int i = 3 / 0;
        } catch (Exception exception) {
            Exceptions.throwSysException(ConsoleErrorCodeEnum.DIVISOR_CAN_NOT_BE_ZERO, exception);
        }
    }

}

前端进行预设样式的提示。

已有的错误处理融合

如果已经有自己的错误处理了，跟统一异常处理进行融合，融合方式具体情况具体分析。提供统一的扩展方式。

可单独找 @李福春(lifuchun) 一起看整改方式 。

工程分工和任务跟进

完成标志：在测试环境中提示规范，有价值。

明确指出是哪个服务的什么问题，建议提示一定要准确到位。 测试做验证。

小结

作为一名程序员，需要站在更高的角度，用产品思维，系统思维，终局思维，商业运营思维去看待出现的痛点问题。

通过从前到后的约定错误和异常提示，解决各个岗位对软件系统排错性的建设。

下期我直接输出一个统一的java异常处理的后端SDK样例。

原创不易，关注诚可贵，转发价更高！转载请注明出处，让我们互通有无，共同进步，欢迎沟通交流。