错误处理的几种套路
在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
}
本质就是额外包了一层结构体而已
总结
这些方式在简单的项目中怎么样的可以,但是在大的项目工程中就需要形成一定的规范