error 封装
Error, Exception & Panic
1. Error
错误是程序中可能出现的问题，比如连接数据库失败，连接网络失败等，在程序设计中，错误处理是业务的一部分。
Go内建一个error接口类型作为go的错误标准处理: http://golang.org/pkg/builtin/#error
// 接口定义
type error interface {
Error() string
}
http://golang.org/src/pkg/errors/errors.go
// 实现
func New(text string) error {
return &errorString{text}
}
type errorString struct {
s string
}
func (e *errorString) Error() string {
return e.s
}
2. Exception
异常是指在不该出现问题的地方出现问题，是预料之外的，比如空指针引用，下标越界，向空map添加键值等。
人为制造被自动触发的异常，比如：数组越界，向空map添加键值对等。
手工触发异常并终止异常，比如：连接数据库失败主动panic。
异常则是意料之外的，甚至你认为在编码中不可能发生的，Go遇到异常会自动触发panic（恐慌），触发panic程序会自动退出。除了程序自动触发异常，一些你认为不可允许的情况你也可以手动触发异常。
3. Panic
对于真正意外的情况，那些表示不可恢复的程序错误，不可恢复才使用panic。对于其他的错误情况，我们应该是期望使用error来进行判定。
go源代码很多地方写panic, 但是工程实践业务代码不要主动写panic，
理论上panic只存在于server启动阶段，比如config文件解析失败，端口监听失败等等，
所有业务逻辑禁止主动panic【除了框架主动抛出exit请求流程】，所有异步的goroutine都要用recover去兜底处理。
常见错误处理
1. 直观的返回error：
func (d *userConfigDao) saveConfig(ctx context.Context, config *model.UserConfig, updateData interface{}) error {
_, e := d.Ctx(ctx).Data(g.Map{d.Columns.Config: updateData}).
Where(d.Columns.UserId, config.UserId).
Update()
if e != nil {
logger.Dao().Errorf("update config error, %+v, %+v", e, config)
return errors.New("SaveConfig failed")
}
return nil
}
2. 屏蔽过程中的error的处理
将error保存到对象内部，处理逻辑交给每个方法，本质上仍是顺序执行。标准库的bufio、database/sql包中的Rows等都是这样实现的，
type ZooTour interface {
Enter() error
VisitPanda(panda *Panda) error
Leave() error
Err() error
}
func Tour(t ZooTour, panda *Panda) error {
t.Enter()
t.VisitPanda(panda)
t.Leave()
// 集中编写业务逻辑代码,最后统一处理error
if err := t.Err(); err != nil {
return errors.WithMessage(err, "ZooTour failed")
}
return nil
}
3. 利用函数式编程延迟运行
type Walker interface {
Next MyFunc
}
type SliceWalker struct {
index int
funs []MyFunc
}
func NewEnterFunc() MyFunc {
return func(t ZooTour) error {
return t.Enter()
}
}
func BreakOnError(t ZooTour, walker Walker) error {
for {
f := walker.Next()
if f == nil {
break
}
if err := f(t); err := nil {
// 遇到错误break或者continue继续执行
}
}
}
上面这三个例子，是Go项目处理错误使用频率最高的三种方式，也可以应用在error以外的处理逻辑。
- case1: 如果业务逻辑不是很清楚，比较推荐case1；
- case2: 代码很少去改动，类似标准库，可以使用case2；
- case3: 比较复杂的场景，复杂到抽象成一种设计模式。
分层下的Error Handling
在工程实践中，以一个常见的三层架构（dao->service->controller）为例，我们常见的错误处理方式大致如下：
// controller
if err := mode.ParamCheck(param); err != nil {
log.Errorf("param=%+v", param)
return errs.ErrInvalidParam
}
return mode.ListTestName("")
// service
_, err := dao.GetTestName(ctx, settleId)
if err != nil {
log.Errorf("GetTestName failed. err: %v", err)
return errs.ErrDatabase
}
// dao
if err != nil {
log.Errorf("GetTestDao failed. uery: %s error(%v)", sql, err)
return err
}
- 分层开发导致的处处打印日志；
- 难以获取详细的堆栈关联；
- 根因丢失。
Wrap errors
Go相关的错误处理方法很多，但大多为过渡方案，这里就不一一分析了（类似github.com/juju/errors库，有兴趣可以了解）。这里我以github.com/pkg/errors为例，这个也是官方Proposal的重点参考对象。
目的：
- 错误要被日志记录；
- 应用程序处理错误，保证100%完整性；
- 之后不再报告当前错误（错误只被处理一次）。
github.com/pkg/errors包主要包含以下几个方法，如果我们要新生成一个错误，可以使用New函数,生成的错误，自带调用堆栈信息。如果有一个现成的error ，我们需要对他进行再次包装处理，这时候有三个函数可以选择（WithMessage/WithStack/Wrapf）。其次，如果需要对源错误类型进行自定义判断可以使用Cause,可以获得最根本的错误原因。
// 新生成一个错误, 带堆栈信息
func New(message string) error
// 只附加新的信息
func WithMessage(err error, message string) error
// 只附加调用堆栈信息
func WithStack(err error) error
// 同时附加堆栈和信息
func Wrapf(err error, format string, args ...interface{}) error
// 获得最根本的错误原因
func Cause(err error) error
以常见的一个三层架构为例：
- Dao层使用Wrap上抛错误
if err != nil {
if errors.Is(err, sql.ErrNoRows) {
return nil, errors.Wrapf(ierror.ErrNotFound, "query:%s", query)
}
return nil, errors.Wrapf(ierror.ErrDatabase, "query: %s error(%v)", query, err)
}
- Service层追加信息
result, err := a.Dao.GetName(ctx, param)
if err != nil {
return result, errors.WithMessage(err, "GetName failed")
}
- MiddleWare统一打印错误日志
// 请求响应组装
func Handle(next http.MiddleFunc) http.MiddleFunc {
return func(ctx context.Context, req *http.Request, rsp *http.Response) error {
format := &format{Time: time.Now().Unix()}
err := next(ctx, req, rsp)
format.Data = rsp.Data
if err != nil {
format.Code, format.Msg = errCodes(ctx, err)
}
rsp.Data = format
return nil
}
}
// 获取错误码, 国际化响应消息体
func errCodes(ctx context.Context, err error) (int, string) {
if err != nil {
log.CtxErrorf(ctx, "error: [%+v]", err)
}
var myError = new(erro.IError)
if errors.As(err, &myError) {
return myError.Code, myError.Msg
}
return code.ServerError, i18n.CodeMessage(code.ServerError)
}
- 和其他库进行协作
如果和其他库进行协作，考虑使用errors.Wrap或者errors.Wrapf保存堆栈信息。同样适用于和标准库协作的时候。
_, err := os.Open(path)
if err != nil {
return errors.Wrapf(err, "Open failed. [%s]", path)
}
- 包内如果调用其他包内的函数，通常简单的直接return err
defer 处理
func InsertDao(ctx context.Context) (err error) {
defer fun(){
if err != nil{
err = Wrap(err, "detail info") // 不返回原始error
}
}
// DOING
}
组件封装 自定义处理 ERROR
期望
// x 库中提供的，此默认为会返回的原err
// 如果从原始层一直都是在包装，未替换，则不会是Code, 此方法会返回原始的err信息给到resp
func Error(r *ghttp.Response, err error, opts ...opt) {
if errCode, ok := gerror.Cause(err).(Code); ok {
opts = append([]opt{WithCode(errCode)}, opts...)
}
writeResult(r, errorRO(err, opts...))
}
- gerror.Wrap 包装原生err，添加堆栈与详细信息
func InsertDao(ctx context.Context) (err error) {
// DOING
return gerror.Wrap(sqlErr, "发生错误")
}
// 简单测试
func TestXGfErr(t *testing.T) {
sqlErr := new1()
// 直接 wrap 原生错误
e := gerror.Wrap(sqlErr, "发生错误")
resp := &ghttp.Response{
ResponseWriter: &ghttp.ResponseWriter{},
}
// 简单打桩，替换掉写数据给 resp
patches := gomonkey.ApplyMethod(reflect.TypeOf(resp), "WriteJson", func(resp *ghttp.Response, content interface{}) error {
t.Logf("status: %v \tbody: %+v\n", resp.Status, content)
return nil
})
defer patches.Reset()
// 日志打印，包含堆栈，无法打印gerror外的error的堆栈数据
t.Logf("%+v\n", e)
// 响应给前端，只会响应codeXX的内容
response.Error(resp, e)
}
// 模拟产生原始err
func new1() error {
return new2()
}
func new2() error {
return pkgerr.New("错误sql源")
}
会将原生错误返回给前端
- 自定义错误码（Code）
var(
CodeXXErr = response.NewLocalCode(1000,"message","detail",http.StatusBadRequest)
)
func InsertDao(ctx context.Context) (err error) {
// DOING
// LOG ERR
return CodeXXErr // or gerror.WrapCode(codeXX, sqlErr, "包装message")
}
// 简单测试
func TestXGfErr(t *testing.T) {
codeXX := response.NewLocalCode(1000, "登录失败", "账号密码错误", http.StatusBadRequest)
sqlErr := new1()
// 写了text，则会在日志打印中替换掉code中的message, 但响应resp中的不变
e := gerror.WrapCode(codeXX, sqlErr, "包装message")
resp := &ghttp.Response{
ResponseWriter: &ghttp.ResponseWriter{},
}
// 简单打桩，替换掉写数据给 resp
patches := gomonkey.ApplyMethod(reflect.TypeOf(resp), "WriteJson", func(resp *ghttp.Response, content interface{}) error {
t.Logf("status: %v \tbody: %+v\n", resp.Status, content)
return nil
})
defer patches.Reset()
// 日志打印，包含堆栈，无法打印gerror外的error的堆栈数据
t.Logf("%+v\n", e)
// 响应给前端，只会响应codeXX的内容
response.Error(resp, e)
}
// 模拟产生原始err
func new1() error {
return new2()
}
func new2() error {
return pkgerr.New("错误sql源")
}
直接对Code wrap err 没有正确处理Code
而且
- 【WARN】: 在接口请求时，会泄露数据库内部结构
新增处理
// 新增
// 写错误给response时，优先判断error中的Code
// Error中的err还是为原始error，或者依靠原始err进行的wrap
// 但是Code为自定义的错误，此Code会用于响应给请求，不会将原始err暴露出去
// 正常提供 %+v 打印err时，会将原始err 与函数调用栈给打印出来，而且可以忽略Code打印
func Error2(r *ghttp.Response, err error, opts ...opt) {
if er, ok := err.(*gerror.Error); ok {
if errCode, ok := er.Code().(Code);ok{
opts = append([]opt{WithCode(errCode)}, opts...)
}
}
writeResult(r, errorRO(err, opts...))
// errorRO 会 处理 Code 以及 成功请求
}
// 简单测试
func TestXGfErr(t *testing.T) {
codeXX := response.NewLocalCode(1000, "登录失败", "账号密码错误", http.StatusBadRequest)
sqlErr := new1()
// 写了text，则会在日志打印中替换掉code中的message, 但响应resp中的不变
e := gerror.WrapCode(codeXX, sqlErr, "包装message")
resp := &ghttp.Response{
ResponseWriter: &ghttp.ResponseWriter{},
}
// 简单打桩，替换掉写数据给 resp
patches := gomonkey.ApplyMethod(reflect.TypeOf(resp), "WriteJson", func(resp *ghttp.Response, content interface{}) error {
t.Logf("status: %v \tbody: %+v\n", resp.Status, content)
return nil
})
defer patches.Reset()
// 日志打印，包含堆栈，无法打印gerror外的error的堆栈数据
t.Logf("%+v\n", e)
// 响应给前端，只会响应codeXX的内容
response.Error2(resp, e)
}
// 模拟产生原始err
func new1() error {
return new2()
}
func new2() error {
return pkgerr.New("错误sql源")
}
- 针对业务错误设计对应的错误码，错误信息，以及针对性的http状态码
- 当正常在这个业务中时，可直接使用这个错误变量，必要时可通过(code).WithDetail改变返回的详细信息
- 在return时, 通过gerror.WrapCode(code, err, text)
- 在打日志时，可跳过err中code相关信息打印，因为请求日志内会有
- 在输出响应给resp时，不会将原始 err 数据输出，只会输出code与withMessage内容
- gerror包装了原始err后，会丢失原始err保存的调用栈，如果原始err是通过github/pkg/errors返回的错误的话。
日志只处理一次
- 在dao层，只抛出具体错误，如有需要添加的错误详情内容可通过 wrap or withMessage 方法包装添加详情与栈信息
- 在dao层可直接将sql或者其他工具报的错误，通过自定义错误结构【如上组件封装】预定义的错误变量返回
- 在service层可统一处理防腐层，dao层出现的错误，通过 %+v 占位符将错误的堆栈信息一并打印，也可实现fmt.Formatter接口处理
- api层则只接受请求，解析参数
- 在api层执行完后，在写数据返回前，对出现的err作断言判断，如果是自定义错误，则返回自定义错误预定的code和msg
- 尽量避免在出现一次错误时，重复性打多条ERROR日志记录
关键点总结：
- MyError【自定义错误】作为全局error的底层实现，保存具体的错误码和错误信息；
- MyError向上返回错误时，第一次先用Wrap初始化堆栈，后续用WithMessage增加堆栈信息；
- 要判断error是否为指定的错误时，可以使用errors.Cause获取root error，再进行和 MyError断言判定；
- github.com/pkg/errors和标准库的error完全兼容，可以先替换、后续改造历史遗留的代码；
- 打印error的堆栈需要用%+v，而原来的%v依旧为普通字符串方法；同时也要注意日志采集工具是否支持多行匹配；
- log error级别的打印栈:%+v，warn和info可不打印堆栈：%v；
- 过多的自定义错误码，在接口文档的维护上会有点辛苦，现在前端并不都已响应中的code为状态码，而是http.status处理
并发处理时，errgroup集中处理错误
官方的ErrGroup非常简单，其实就是解决小型多任务并发任务。
基本用法golang.org/x/sync/errgroup包下定义了一个Group struct，它就是我们要介绍的ErrGroup并发原语，底层也是基于WaitGroup实现的。
在使用ErrGroup时，我们要用到三个方法，分别是WithContext、Go和Wait。
通常，在写业务代码性能优化时经常将一个通用的父任务拆成几个小任务并发执行。此时需要将一个大的任务拆成几个小任务并发执行，来提高QPS，我们需要再业务代码里嵌入以下逻辑，但这种方式存在问题：
- 每个请求都开启goroutinue，会有一定的性能开销。
- 野生的goroutinue，生命周期管理比较困难。
- 收到类似SIGQUIT信号时，无法平滑退出
type Group struct {
cancel func()
wg sync.WaitGroup
errOnce sync.Once
err error
}
// WithContext returns a new Group and an associated Context derived from ctx.
//
// The derived Context is canceled the first time a function passed to Go
// returns a non-nil error or the first time Wait returns, whichever occurs
// first.
func WithContext(ctx context.Context) (*Group, context.Context) {
ctx, cancel := context.WithCancel(ctx)
return &Group{cancel: cancel}, ctx
}
// Wait blocks until all function calls from the Go method have returned, then
// returns the first non-nil error (if any) from them.
func (g *Group) Wait() error {
g.wg.Wait()
if g.cancel != nil {
g.cancel()
}
return g.err
}
// Go calls the given function in a new goroutine.
//
// The first call to return a non-nil error cancels the group; its error will be
// returned by Wait.
func (g *Group) Go(f func() error) {
g.wg.Add(1)
go func() {
defer g.wg.Done()
if err := f(); err != nil {
g.errOnce.Do(func() {
g.err = err
if g.cancel != nil {
g.cancel()
}
})
}
}()
}
整个包就一个Group结构体：
- 通过WithContext可以创建一个带取消的Group；
- 当然除此之外也可以零值的Group也可以直接使用，但是出错之后就不会取消其他的goroutine了；
- Go方法传入一个func() error内部会启动一个goroutine去处理；
- Wait类似WaitGroup的Wait方法，等待所有的goroutine结束后退出，返回的错误是一个出错的err。
注意这里有一个坑，在后面的代码中不要把ctx当做父 context又传给下游，因为errgroup取消了，这个context就没用了，会导致下游复用的时候出错
func TestErrgroup(t *testing.T) {
eg, ctx := errgroup.WithContext(context.Background())
for i := 0; i < 100; i++ {
i := i
eg.Go(func() error {
time.Sleep(2 * time.Second)
select {
case <-ctx.Done():
fmt.Println("Canceled:", i)
return nil
default:
fmt.Println("End:", i)
return nil
}})}
if err := eg.Wait(); err != nil {
log.Fatal(err)
}
select {
case <-ctx.Done():
// 会直接走这个分支
fmt.Println("--- again close stop")
default:
fmt.Println("=== again stop")
}
}
errgroup 开展包
B站拓展包 （https://github.com/go-kratos/kratos/blob/v0.3.3/pkg/sync/errgroup/errgroup.go）
// A Group is a collection of goroutines working on subtasks that are part of
// the same overall task.
//
// A zero Group is valid and does not cancel on error.
type Group struct {
err error
wg sync.WaitGroup
errOnce sync.Once
workerOnce sync.Once
ch chan func(ctx context.Context) error
chs []func(ctx context.Context) error
ctx context.Context
cancel func()
}
// WithContext create a Group.
// given function from Go will receive this context,
func WithContext(ctx context.Context) *Group {
return &Group{ctx: ctx}
}
// WithCancel create a new Group and an associated Context derived from ctx.
//
// given function from Go will receive context derived from this ctx,
// The derived Context is canceled the first time a function passed to Go
// returns a non-nil error or the first time Wait returns, whichever occurs
// first.
func WithCancel(ctx context.Context) *Group {
ctx, cancel := context.WithCancel(ctx)
return &Group{ctx: ctx, cancel: cancel}
}
func (g *Group) do(f func(ctx context.Context) error) {
ctx := g.ctx
if ctx == nil {
ctx = context.Background()
}
var err error
defer func() {
if r := recover(); r != nil {
buf := make([]byte, 64<<10)
buf = buf[:runtime.Stack(buf, false)]
err = fmt.Errorf("errgroup: panic recovered: %s\n%s", r, buf)
}
if err != nil {
g.errOnce.Do(func() {
g.err = err
if g.cancel != nil {
g.cancel()
}
})
}
g.wg.Done()
}()
err = f(ctx)
}
// GOMAXPROCS set max goroutine to work.
// GOMAXPROCS函数其实是起了一个并发池来控制协程数量，传入最大协程数量进行并发消费管道里的函数签名：
func (g *Group) GOMAXPROCS(n int) {
if n <= 0 {
panic("errgroup: GOMAXPROCS must great than 0")
}
g.workerOnce.Do(func() {
g.ch = make(chan func(context.Context) error, n)
for i := 0; i < n; i++ {
go func() {
for f := range g.ch {
g.do(f)
}
}()
}
})
}
// Go calls the given function in a new goroutine.
//
// The first call to return a non-nil error cancels the group; its error will be
// returned by Wait.
// Go方法可以看出并不是直接起协程的（如果管道已经初始化好了），而是优先将函数签名放入管道，管道如果满了就放入切片。
func (g *Group) Go(f func(ctx context.Context) error) {
g.wg.Add(1)
if g.ch != nil {
select {
case g.ch <- f:
default:
g.chs = append(g.chs, f)
}
return
}
go g.do(f)
}
// Wait blocks until all function calls from the Go method have returned, then
// returns the first non-nil error (if any) from them.
func (g *Group) Wait() error {
if g.ch != nil {
for _, f := range g.chs {
g.ch <- f
}
}
g.wg.Wait()
if g.ch != nil {
close(g.ch) // let all receiver exit
}
if g.cancel != nil {
g.cancel()
}
return g.err
}
整个流程梳理下来其实就是启动一个固定数量的并发池消费任务，Go函数其实是向管道中发送任务的生产者，这个设计中有意思的是他的协程生命周期的控制，他的控制方式是每发送一个任务都进行WaitGroup加一，在最后结束时的wait函数中进行等待，等待所有的请求都处理完才会关闭管道，返出错误。
- B站拓展包主要解决了官方ErrGroup的几个痛点：控制并发量、Recover住协程的Panic并打出堆栈信息。
- Go方法并发的去调用在量很多的情况下会产生死锁，因为他的切片不是线程安全的，如果要并发，并发数量一定不能过大，一旦动用了任务切片，那么很有可能就在wait方法那里hold住了。这个可以加个锁来优化。
- Wg watigroup只在Go方法中进行Add()，并没有控制消费者的并发，Wait的逻辑就是分发者都分发完成，直接关闭管道，让消费者并发池自行销毁，不去管控，一旦逻辑中有完全hold住的方法那么容易产生内存泄漏。
扫一扫
1056
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
