call stack是什么错误_Go语言(golang)的错误(error)处理的推荐方案

原文链接：https://www.flysnow.org/2019/01/01/golang-error-handle-suggestion.html
微信公众号:flysnow_org（飞雪无情）

对于Go语言（golang）的错误设计，相信很多人已经体验过了，它是通过返回值的方式，来强迫调用者对错误进行处理，要么你忽略，要么你处理（处理也可以是继续返回给调用者），对于golang这种设计方式，我们会在代码中写大量的if判断，以便做出决定。

func main() {conent,err:=ioutil.ReadFile("filepath")if err !=nil{//错误处理}else {fmt.Println(string(conent))}
}

这类代码，在我们编码中是非常的，大部分情况下error都是nil，也就是没有任何错误，但是非nil的时候，意味着错误就出现了，我们需要对他进行处理。

error 接口

error其实一个接口，内置的，我们看下它的定义

// The error built-in interface type is the conventional interface for
// representing an error condition, with the nil value representing no error.
type error interface {Error() string
}

它只有一个方法 Error，只要实现了这个方法，就是实现了error。现在我们自己定义一个错误试试。

type fileError struct {}func (fe *fileError) Error() string {return "文件错误"
}

自定义 error

自定义了一个fileError类型，实现了error接口。现在测试下看看效果。

func main() {conent, err := openFile()if err != nil {fmt.Println(err)} else {fmt.Println(string(conent))}
}//只是模拟一个错误
func openFile() ([]byte, error) {return nil, &fileError{}
}

我们运行模拟的代码，可以看到文件错误的通知。

在实际的使用过程中，我们可能遇到很多错误，他们的区别是错误信息不一样，一种做法是每种错误都类似上面一样定义一个错误类型，但是这样太麻烦了。我们发现Error返回的其实是个字符串，我们可以修改下，让这个字符串可以设置就可以了。

type fileError struct {s string
}func (fe *fileError) Error() string {return fe.s
}

恩，这样改造后，我们就可以在声明fileError的时候，设置好要提示的错误文字，就可以满足我们不同的需要了。

//只是模拟一个错误
func openFile() ([]byte, error) {return nil, &fileError{"文件错误，自定义"}
}

恩，可以了，已经达到了我们的目的。现在我们可以把它变的更通用一些，比如修改fileError的名字，再创建一个辅助函数，便于我们创建不同的错误类型。

//blog:www.flysnow.org
//wechat:flysnow_org
func New(text string) error {return &errorString{text}
}type errorString struct {s string
}func (e *errorString) Error() string {return e.s
}

变成以上这样，我们就可以通过New函数，辅助我们创建不同的错误了，这其实就是我们经常用到的errors.New函数，被我们一步步剖析演化而来，现在大家对Go语言(golang)内置的错误error有了一个清晰的认知了。

存在的问题

虽然Go语言对错误的设计非常简洁，但是对于我们开发者来说，很明显是不足的，比如我们需要知道出错的更多信息，在什么文件的，哪一行代码？只有这样我们才更容易的定位问题。

还有比如，我们想对返回的error附加更多的信息后再返回，比如以上的例子，我们怎么做呢？我们只能先通过Error方法，取出原来的错误信息，然后自己再拼接，再使用errors.New函数生成新错误返回。

如果我们以前做过java开发，我们知道Java的异常是可以嵌套的，也就是说，通过这个，我们很容易知道错误的根本原因，因为Java的异常，是一层层的嵌套返回的，不管中间经历了多少包装，我们可以通过cause找到根本错误的原因。

解决问题

如果要解决以上的问题，那么首先我们必须再继续扩充我们的errorString，再增加一些字段来存储更多的信息。比如我们要记录堆栈信息。

type stack []uintptr
type errorString struct {s string*stack
}

欢迎关注微信公众号flysnow_org或者博客网站 https://www.flysnow.org/ 查看更多原创文章。

有了存储堆栈信息的stack字段，我们在生成错误的时候，就可以把调用的堆栈信息存储在这个字段里。

//blog:www.flysnow.org
//wechat:flysnow_orgfunc callers() *stack {const depth = 32var pcs [depth]uintptrn := runtime.Callers(3, pcs[:])var st stack = pcs[0:n]return &st
}func New(text string) error {return &errorString{s:   text,stack: callers(),}
}

完美解决，现在如果再解决，对现有的错误附加一些信息的问题呢？相信大家应该有思路了。

type withMessage struct {cause errormsg   string
}func WithMessage(err error, message string) error {if err == nil {return nil}return &withMessage{cause: err,msg:   message,}
}

使用WithMessage函数，对原来的error包装下，就可以生成一个新的带有包装信息的错误了。

小结

通过使用这个 github.com/pkg/errors 错误库，我们可以收集更多的信息，可以让我们更容易的定位问题。

我们收集的这些信息不止可以输出到控制台，也可以当做日志，使用输出到相应的Log日志里，便于分析问题。

据说这个库，会被加入到Golang 标准 SDK 里，期待着，如果加入的话，应该就是补充现在标准库里的errors 这个package了。

本文为原创文章，转载注明出处,欢迎扫码关注公众号flysnow_org或者网站asf http://www.flysnow.org/，第一时间看后续精彩文章。觉得好的话，请猛击文章右下角「好看」，感谢支持。