用了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的高可用和高度灵活，错误处理是非常基础且非常重要的一环，需要好好处理
