gowWeb之错误处理和返回响应

Go Web开发进阶实战（gin框架） 讲师：李文周老师

https://study.163.com/course/introduction.htm?courseId=1210171207&trace_c_p_k2=09f1339f33db432ab570cbf2e92c15b0

CLD架构的错误，参数和响应处理

路由请求进来以后,由routes转发到Controller层，

Controller层负责处理路由、参数校验、请求转发。

Controller层调用Logic层的函数，请求转发到Logic层

Logic层负责处理业务逻辑。Logic调用Dao层

DAO负责数据与存储相关功能

以注册功能为例，走一下流程，体验一下CLD

我们从main函数开始。

初始化配置，每个函数都返回一个err，假如err!=nil,直接控制台上打印到那里出错停止的

注意，这里没打印err。接着return，让主程序停止

• 1.加载配置
• 2.初始化日志
• 3.初始化数据库连接
• 4.初始化Redis连接
• 5.注册路由
• 6.启动服务

举个例子

// 3.初始化数据库连接
if err = repo.InitDB(settings.Conf.MySQLConfig);err != nil{
    fmt.Println("程序退出，因为数据库错误")
    return
}
defer repo.CloseDB()

routes

注册路径，转发请求

r.POST("/login",controller.LoginHandler)

controller

1.获取参数和参数校验

2.业务处理

3.返回响应

1.首先去获取参数和对参数进行校验，七米老师说不能相信前端，万一有恶意攻击就不好了。

2.业务处理中。。。还记得我们在main函数里出错了以后做的啥吗？fmt.Println("程序退出，因为数据库错误") return ，所以我们是在Controller层记录的错误日志。

Controller层调用的Logic层的方法，或者其他的一些方法，都会得到返回值至少包括一个错误。这个错误就是出错了层层往上递，假如Controller层调用Logic层的函数，Logic层的函数又调用了DAO层的函数，假如dao层出错了，就会停止执行，然后返回一个err给Logic层，logic层发现错误不为空后，也停止执行，把错误往Controller层送，最终的错误值就在Controller层，所以我们在Controller层要判断错误，假如错误不为空，那么就记录在日志了，给前端一个响应后停止执行。

3.返回响应。出错了以后直接返回响应。假如一直没出错，就返回一个success响应

func SignUpHandler(c *gin.Context) {
	var err error
	// 1.获取参数和参数校验
	var p = new(models.ParamSignUp)
	// 这个p是指向结构体的指针类型
	if err = c.ShouldBindJSON(p); err != nil {
		//请求参数有误，直接返回响应
		zap.L().Error("SignUp with unValid Param", zap.Error(err))
		//类型断言，判断err是不是validator类型
		errs, ok := err.(validator.ValidationErrors)
		//   注意这里，这个errs不是error类型，切记切记
		//   不要先声明成error类型，后面的.Translate 会报错的
		if !ok {
			// 非validator.ValidationErrors类型错误直接返回
			ResponseError(c,CodeInvalidParam)
			return
		}
		// validator.ValidationErrors类型错误则进行翻译
		ResponseErrorWithMsg(c,CodeInvalidParam,removeTopStruct(errs.Translate(trans)))
	}

	// 2.业务处理
	if err=service.SignUP(p);err!=nil{
		zap.L().Error("SignUp in Mysql failed", zap.Error(err))
		if errors.Is(err, models.ErrorUserExist){
			ResponseError(c,CodeUserExist)
		}else{
			// 应该是数据库的其他错误
			//错误已经记录在日志里了，这里就是给前端个返回
			ResponseError(c,CodeServerBusy)
		}
		return
	}
	//3.假如没出错返回成功响应
	ResopnseSuccess(c,nil)
}

Logic 层

Logic层就对业务进行处理呗，调用dao层的方法和函数

func SignUP(p *models.ParamSignUp) (err error){
// 1.判断用户是否已经存在
if err = mysql.CheckUserExist(p.UserName);err!=nil{
	return err
}
// 2.生成UID
userID :=snowflake.GenID()
//创建一个user实例
var u = models.User{
	UserID: userID,
	UserName: p.UserName,
	Password: p.PassWord,
}
// 3.保存进数据库
err = mysql.InsertUser(&u)
return err
}

Dao

数据库存储

func CheckUserExist(username string) (err error){
	sqlStr := "select count(user_id) from user where username = ?"
	var count int
	if err = db.Get(&count,sqlStr,username);err!=nil{
		return err
	}
   if count >0 {
	  return models.ErrorUserExist
   }
	return
}
func InsertUser(u *models.User) error{
// 对密码进行加密
u.Password = encryptPassword(u.Password)
sqlStr:="insert into user(user_id,username,password) values(?,?,?)"
_,err:=db.Exec(sqlStr,u.UserID,u.UserName,u.Password)
return err
}

参数

我们可以看到，Controller层传下去的参数是models.ParamSignUp，而到了Logic层传下去的就变成了models.User，也就是真正对应数据库的表所建的模型。

有啥区别呢，就是Param就是前端给啥或者要啥，就做这样的结构体。比如前端要个首页的帖子列表，那就ParamPost只需要标题，作者，还有内容的一部分。而比如Post是和数据库进行交互，数据库有啥，它就有啥。

注意：这属于模型的两种方面，放一个包里，但不要放在一个go文件里,

//与前端联系
type ParamSignUp struct{
	UserName string `json:"username"`
	PassWord string `json:"password"`
    RePassWord string `json:"re_password"`
}
//与后端数据库联系
type User struct{
	UserID int64 `db:"user_id"`
	UserName string `db:"username"`
    Password string `db:"password"`
}

错误和状态码和响应

c.JSON(http.StatusOK, gin.H{

""msg": err.Error(),})

太琐碎了，所以定义业务状态码，并封装响应方法。如何判断业务状态码呢，看错误的类型。所以我们又自定义了错误类型。现在，错误，状态码和响应方法有对应关系了。

另外给响应方法一个固定格式，这样前端也方便处理。

error

//我在model层的error.go定义的定制错误
var(
	ErrorUserExist= errors.New("用户已存在")
	ErrorUserNotExist = errors.New("用户不存在")
	ErrorNotMatch = errors.New("用户名或密码错误")
)

所以之前的数据库文件中，注册查询到用户名已存在，返回models.ErrorUserExist

登录时查不到该用户，返回models.ErrorUserNotExist

因为错误不可能都定义完，有些也不能去定义，查询时出错，你知道是哪错了吗？。所以一部分判断不了的直接返回这个err。

在Controller层，假如err!=nil,对err进行判断errors.Is(myerr, targetErr)

,然后选择对应的状态码和响应

code

因为只有在Controller层我们返回请求，所以code和Resonse就直接放在Controller层了

//code
package controller
//这里定义的状态码
type Rescode int64
//在const里使用了iota自增
const(
	CodeSuccess Rescode = 1000+ iota
	CodeInvalidParam
	CodeUserExist
	CodeUserNotExist
	CodeNotMatch
	CodeServerBusy
)
//给对应状态码加上消息
var codeMsgMap = map[Rescode]string{
	CodeSuccess :"success",
	CodeInvalidParam:"请求参数错误",
	CodeUserExist:"用户名已存在",
	CodeUserNotExist:"用户不存在",
	CodeNotMatch:"用户名或密码错误",
	CodeServerBusy:"服务器繁忙",
	// 比如数据库连接错误啥的，前端不用知道，
	// 就说服务器繁忙就行
}
//获得对应状态码的消息
func (c Rescode) GetMsg() string{
	msg,ok := codeMsgMap[c]
	if !ok{
		msg = codeMsgMap[CodeServerBusy]
	}
	return msg
}

Response

package controller

import (
	"github.com/gin-gonic/gin"
	"net/http"
)

/*
封装响应方法，固定格式，方便前端
{
	"code":  , //程序中的错误码
	"msg":     ,// 错误的提示信息
	"data":{}      //数据
}
*/
type ResopnseDate struct{
    Code Rescode       `json:"code"`
	Msg interface{}    `json:"msg"`
	Date interface{}   `json:"data"`
}

func ResponseError(c *gin.Context,code Rescode){
//只有状态码
	c.JSON(http.StatusOK,&ResopnseDate{
		Code: code,
		Msg: code.GetMsg(),
		Date: nil,
	})
}
func ResponseErrorWithMsg(c *gin.Context,code Rescode,msg interface{}){
//有状态码和自己的信息
	c.JSON(http.StatusOK,&ResopnseDate{
		Code: code,
		Msg: msg,
		Date: nil,
	})
}
func ResopnseSuccess(c *gin.Context,data interface{}){
//成功以后返回的，自带数据
	c.JSON(http.StatusOK,&ResopnseDate{
		Code: CodeSuccess,
		Msg: CodeSuccess.GetMsg(),
		Date: data,
	})
}

举例子

if err=service.Login(p);err != nil{
        //错误记录在日志里
		zap.L().Error("Login failed", zap.String("username",p.UserName),zap.Error(err))

		if errors.Is(err, models.ErrorUserNotExist){
		//根据错误判断code
			ResponseError(c,CodeUserNotExist)
		}else if errors.Is(err,models.ErrorNotMatch){
			ResponseError(c,CodeNotMatch)
		}else{
			// 应该是数据库的其他错误
			//错误已经记录在日志里了，这里就是给前端个返回
			//y=有些错误没必要让前端知道，前端知道你查询映射数目对不上干嘛？
			//可以直接服务器繁忙
			ResponseError(c,CodeServerBusy)
		}
		return
	 }