golang error 处理

作者: Stevennnmmm | 来源:发表于2020-12-10 17:43 被阅读0次

golang处理error
golang error 处理
golang error与panic处理
Golang中Error处理方案
Go 基础 3：error handling
聊聊golang的error包装
goland常用快捷键
Golang实践-error
聊聊golang的zap的error
Golang正确的Error处理方式

用了golang也有一段时间了，在我推动golang在公司项目应用工程中也发现了很多问题,关于公司的golang工程化落地，我会在这个文集上面简单记录一下，以供以后参考。

golang error

关于这个主题上其实真的有很多话说，我们公司有部分项目是从php转过来的，基本就是API项目。在之前的工程化上主要用的thinkphp，使用框架的上层handler错误其实就挺方便，转到了golang，也可能是刚转过来很多概念性的东西没有理解透彻，错误真的就是到处都是，连四五年的php开发工程师在这上面也出现了很基本的错误

理解方法为什么返回error

我们常常做项目工程上的，都是try catch ，第一次转过来肯定还是有相当部分不适应，但是程序员嘛，就是要有究其根本的魄力。

我们看golang官方怎么描述的error

you only need to check the error value if you care about the result.

理解了的人其实真的觉得这话说的挺不错的，而且是越来越觉得这个比较经典：
如果你在乎结果，你只需要检查一下这个错误值。
我说一个我们公司的例子，是实实在在的例子，工作了四五年的一个工程师，在调用这个方法的时候，选着性忽略掉err的值，说是为了代码好看，为此我还专门开了一个部门会议强调这个点。
所以官方描述这句话的时候我最近越发觉得经典，虽然在入门的时候看了一眼觉得没啥问题，但是现在拿这句话来看我们的代码还是有很多点可以进行改进的

error必须被处理，到底应该在哪里处理？

在顶级处理或者”运行“方法上进行处理！！！！！

首先观点先给你们抛出来，很多人听起来一句带过，之前我也是的，但是看到我们工程的满屏日志的时候我重新审视了一下这句话。我一般把项目分为这两类：

（1）API项目

在api项目的上，我们架构分层大概是：controller ，service ，dao。 controller 进行参数校验，结果返回。service 主要处理逻辑，组装结果。dao层主要就是数据库的操作。按照上面的说法顶级处理或者运行方法处理那么就是在controller这个运行点处理错误并返回结果。

（2）服务项目

一般服务项目就是消耗数据，进行其他的一些操作，我们内部项目一般就抽象成消费生产者模式，那么这种模式下，我们一般是属于消费端，或者两个端都会存在服务中，比如爬虫，发起请求，处理结果，两者都存在程序中。我们依旧是把这个抽象成一个消费生产模式，我们生成一个请求，然后在结构体中包裹回调方法，在具体的handler方法中处理，那么95%的业务报错我都能在运行端记录，也就是handler记录。

如何操作error让我们能够更加优雅

就算解决了上面的error被处理问题：在运行点或者顶级方法记录日志或者报警。
我们还是要在逻辑业务里面写上满屏的:

if err !=nil{
  return err 
}

1 . 选择侵入式的代码，传递指针进入方法，返回错误

func Select(str *string)(err error){
    *str ="contvffadf"
    return
}

2.统一参数传递返回参数，尽可能减少参数的判断
3.重建结构处理错误返回，这个后面补上案例// todo

拿不到堆栈信息怎么办

当我们将所有的错误都返回出去，实际上看过错误源码的人都知道，error内部实际上就是一个字符串，那么该怎么办呢。

强大的error wrap

使用：github.com/pkg/errors
使用这个包下面的方法

package main
import (
    "STL/demo/deni"
    "fmt"
    "github.com/pkg/errors"
)
func main() {
    err :=B()
    fmt.Printf("stack error trace:\n%+v\n",err)
    fmt.Println(err)
    fmt.Println(errors.Cause(err))
}
func B()error {
    return errors.Wrap(deni.Demo2(), "B方法也坏掉了")
}

package deni

import (
    "github.com/pkg/errors"
)

func Demo1 ()error  {
    e := errors.New("原始错误e")
    return e
}


func Demo2 ()error  {
    e := Demo1()
    w := errors.Wrap(e,"包装第一下")
    return w
}

这里是运行的时候的堆栈

stack error trace:
原始错误e
STL/demo/deni.Demo1
        /Users/shenchenxi/go/src/STL/demo/deni/hh.go:8
STL/demo/deni.Demo2
        /Users/shenchenxi/go/src/STL/demo/deni/hh.go:14
main.B
        /Users/shenchenxi/go/src/STL/demo/main.go:17
main.main
        /Users/shenchenxi/go/src/STL/demo/main.go:9
runtime.main
        /usr/local/go/src/runtime/proc.go:203
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1373
包装第一下
STL/demo/deni.Demo2
        /Users/shenchenxi/go/src/STL/demo/deni/hh.go:15
main.B
        /Users/shenchenxi/go/src/STL/demo/main.go:17
main.main
        /Users/shenchenxi/go/src/STL/demo/main.go:9
runtime.main
        /usr/local/go/src/runtime/proc.go:203
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1373
B方法也坏掉了
main.B
        /Users/shenchenxi/go/src/STL/demo/main.go:17
main.main
        /Users/shenchenxi/go/src/STL/demo/main.go:9
runtime.main
        /usr/local/go/src/runtime/proc.go:203
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1373
B方法也坏掉了: 包装第一下: 原始错误e
原始错误e

Process finished with exit code 0

通过以上几点就基本上可以非常工程化的处理error了

这个案例是我们工作中的实际案例，公司内部博文，但是也是我写的啦

API统一错误处理

1.Err错误种类：

第一种是系统错误包括：数据库连接错误，redis连接错误，调用第三方包的错误。这类错误我们不可控制
第二种逻辑错误：eg:参数校验错误，数据读取错误，错误码

2.接口自定义错误类型：

type MyError struct {
    err  string
    Code int64
}

func (m *MyError) Error() string {
    return m.err
}

func New(str string, code int64) error {
    return &MyError{
        err:  str,
        Code: code,
    }
}

3.错误MAP (错误map 配合内部代码错误使用)

所有的逻辑使用内部错误函数，配合错误map来进行向上抛出
所有非逻辑错误都配合github.com/pkg/errors 报错，这种错误可以绑定错误堆栈

3.接管错误（"建议在中间件上面使用这类代码，统一返回给前端"）

func ResponseData(c *gin.Context, err error, data interface{}) {
    if data == "" || data == nil {
        data = make([]int, 0)
    }
    resp := &Response{Data: data,Ret: 0,Msg: "success"}
    if err !=nil{ // 这里是错误模式
        if tem, ok := err.(*myerror.MyError); ok {
            //这是第二类逻辑错误
            resp = &Response{Ret: tem.Code, Msg: myerror.ErrText[tem.Code], Data: make([]int,0)}
        } else {
            // 第一类未知错误
            stack := fmt.Sprintf("stack error trace:\n%+v\n", err) //错误的堆栈
            fmt.Println(stack)
            public.ZapLog.Error(stack)
            //返回给前端
            resp = &Response{Ret: myerror.COMMENT_ERROR, Msg: myerror.ErrText[myerror.COMMENT_ERROR], Data: make([]int,0)}
        }
    }

    c.Header("Access-Control-Allow-Origin", "*")
    c.JSON(200, resp)
    c.Abort()
}

为了API的高可用和高度灵活，错误处理是非常基础且非常重要的一环，需要好好处理