错误处理的几种套路 错误处理的几种套路

错误处理的几种套路

在Go语言中并不支持抛出异常的方式提示错误,而是通过支持多返回值的方式返回error接口、并且支持panic的方式在遇到致命错误时推出程序

致命错误

panic

func F()  {
    panic("panic")
}

func  main() {
    F()
}
panic: panic

goroutine 1 [running]:
main.F(...)
        /Users/zhangyu/go/src/myPrj/main.go:8
main.main()
        /Users/zhangyu/go/src/myPrj/main.go:12 +0x39

panic会终止整个程序并打印堆栈信息

异常保护

panic表示的是致命错误,但是在实际工程实践中并不应该直接就终止程序,比如:web服务可能是部分接口存在问题另一部分还正常工作,如果直接退出程序会导致整个服务不可用并且无法降级处理

func F()  {
    panic("panic")
}

func  main() {
    defer func() {
        e := recover()
        fmt.Println("recover: ", e)
    }()
    F()
}
recover:  panic

通过recover方法就可以在出现panic错误时恢复程序,但是需要明确一点:不要尝试恢复程序,因为此时程序状态已不可知了
常见场景就是在web服务中在出现panic时回复500错误,而不是程序直接挂掉

普通错误

对于一般错误而言,Go语言中规范是通过在返回值的最后一个为error接口来表示错误信息,但是在实际使用当中会有各种各样的问题

errors.New

func F() error {
    return errors.New("f error")
}

func  main() {
    fmt.Println(F())
}
f error

这是最简单的返回错误的方式,但是存在问题:

  • 调用者只能使用字符串比较函数来处理这些错误,在遇到格式化的问题时则束手无策

sentinel error

sentinel error指的是在包中预定义一些错误值然后调用方进行比较

//os/error.go
var (
    ErrInvalid = fs.ErrInvalid // "invalid argument"

    ErrPermission = fs.ErrPermission // "permission denied"
    ErrExist      = fs.ErrExist      // "file already exists"
    ErrNotExist   = fs.ErrNotExist   // "file does not exist"
    ErrClosed     = fs.ErrClosed     // "file already closed"

    ErrNoDeadline       = errNoDeadline()       // "file type does not support deadline"
    ErrDeadlineExceeded = errDeadlineExceeded() // "i/o timeout"
)

这是os包中的错误定义,在代码中通常直接通过==来进行比较,但是会有一些问题:

  • 不能携带一些额外的错误信息,比如文件名之类的
  • 调用方必须在代码中耦合这些错误值,包的暴露面变大同时不能随意变更这些错误信息了

类型断言

type Error struct {
    code int
    msg  string
}

func (e *Error) Error() string {
    return e.msg
}

func F() error {
    return &Error{code: 1,msg: "f error"}
}

func  main() {
    err := F()
    if e, ok := err.(*Error); ok {
        fmt.Println(e.msg, e.code)
    }
}

类型断言的方式很简单就是返回一个实现error接口的自定义的结构体,外部则根据结构体中的信息来处理,比较常见的方式可以定义错误码
这样导致的问题就是调用者和包存在较大的耦合关系

opaque error

opaque error的思想就是提供函数接口来判断错误类型而不是直接操纵结构体字段

//包
type myerror struct {
    Code int
    Msg  string
}

func (e *myerror) Error() string {
    return e.Msg
}


func F() error {
    return &myerror{Code: 1,Msg: "f error"}
}

func IsError1(err error) bool {
    if e, ok := err.(*myerror); ok {
        if e.Code == 1 {
            return true
        }
    }
    return false
}
//主函数
func  main() {
    err := F()
    if IsError1(err) {
        fmt.Println("error 1")
    }
}

主要的思想就是对外提供函数而不是结构体,包的更新维护更加的方便

错误堆栈

在实际工作当中需要的也许不仅仅是错误信息还需要错误堆栈

package main

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

type MyError struct {
    Code int
    Msg  string
}

func (e *MyError) Error() string {
    return e.Msg
}


func F() error {
    e := &MyError{Code: 1,Msg: "f execute error"}
    return errors.Wrap(e, "[errors wrap]");
}

type stackTracer interface {
    StackTrace() errors.StackTrace
}

func  main() {
    e := F()
    var mye *MyError
    if  errors.As(e, &mye) {
        fmt.Println("mye: ", mye.Code, mye.Msg)
    }
    if err, ok := e.(stackTracer); ok {
        for _, f := range err.StackTrace() {
            fmt.Printf("%+s:%d\n", f, f)
        }
    }
}
mye:  1 f execute error
main.F
        /Users/zhangyu/go/src/myPrj/main.go:20
main.main
        /Users/zhangyu/go/src/myPrj/main.go:28
runtime.main
        /usr/local/Cellar/go/1.16.5/libexec/src/runtime/proc.go:225
runtime.goexit
        /usr/local/Cellar/go/1.16.5/libexec/src/runtime/asm_amd64.s:1371

github.com/pkg/errors包提供了很多增强方法用来包装错误信息、类型断言等等,在fmt包中的fmt.Errorf%w占位符是类似的

type withMessage struct {
    cause error
    msg   string
}

本质就是额外包了一层结构体而已

总结

  这些方式在简单的项目中怎么样的可以,但是在大的项目工程中就需要形成一定的规范

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章