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
	 }
posted @ 2023-06-05 09:07  id_shiguang  阅读(114)  评论(0编辑  收藏  举报