Go语言错误和异常处理机制

2018-08-21 本文已影响0人一根很帅的藤藤菜

错误和异常的区别

错误和异常是不同的概念
错误指的是可能出现问题的地方出现了问题，比如打开一个文件时失败，这种情况在人们的意料之中；而异常指的是不应该出现问题的地方出现了问题，比如引用了空指针，这种情况在人们的意料之外。可见，错误是业务过程的一部分，而异常不是
从Go语言机制上讲，错误和异常就是error和panic的区别
Go语言错误和异常是可以互相转换的：

错误转异常，如程序尝试请求某个URL，最多尝试三次，尝试三次的过程中请求失败是错误，尝试完第三次还不成功的话，失败就被提升为异常了
异常转错误，如panic触发的异常被recover恢复后，将返回值中error类型的变量进行赋值，以便上层函数继续走错误处理流程

Go语言错误处理机制

error

Go 语言通过内置的错误接口提供了非常简单的错误处理机制

type error interface {
    Error() string
}

Go提供了两种创建一个实现了error interface的类型的变量实例的方法：errors.New和fmt.Errorf

errors.New("your first error code")
fmt.Errorf("error value is %d\n", errcode)

如果函数要返回错误，则在返回值类型列表中包含error，使用errors.New 可返回一个错误信息

func Sqrt(f float64) (float64, error) {
    if f < 0 {
        return 0, errors.New("math: square root of negative number")
    }
}
//调用函数
result, err:= Sqrt(-1)
if err != nil {
   fmt.Println(err)
}

错误处理的正确姿势

失败的原因只有一个，所以返回值的类型应该为bool，而不是error
没有失败时，不使用error
error应放在返回值类型列表的最后
错误值统一定义，而不是跟着感觉走
参考C/C++的错误码定义文件，在Go的每个包中增加一个错误对象定义文件，如下所示：

var ERR_EOF = errors.New("EOF") 
var ERR_CLOSED_PIPE = errors.New("io: read/write on closed pipe") 
var ERR_NO_PROGRESS = errors.New("multiple Read calls return no data or error") 
var ERR_SHORT_BUFFER = errors.New("short buffer") 
var ERR_SHORT_WRITE = errors.New("short write") 
var ERR_UNEXPECTED_EOF = errors.New("unexpected EOF")

错误逐层传递时，层层都加日志
当尝试几次可以避免失败时，不要立即返回错误
当上层函数不关心错误时，建议不返回error，打印日志即可
当发生错误时，不忽略有用的返回值
error的string context中的内容格式：头母小写，结尾不带标点
不要忽略函数或方法返回的错误码，Check it
可在defer中处理error

Go语言异常处理机制

Go语言追求简洁优雅，所以，Go语言不支持传统的 try…catch…finally 这种异常，因为Go语言的设计者们认为，将异常与控制结构混在一起会很容易使得代码变得混乱。导致开发者很容易滥用异常，甚至一个小小的错误都抛出一个异常。不要用异常代替错误，更不要用来控制流程
在极个别的情况下，也就是说，遇到真正的异常的情况下（比如除数为0了）。才使用Go中引入的异常处理函数
Go中引入两个内置函数panic和recover来触发和终止异常处理流程，同时引入关键字defer来延迟执行defer后面的函数，用于处理异常
panic和recover函数在作用层面分别对等throw和catch语句，当然也存在不同之处，panic和recover函数适用于那些真正的异常（例如整数除0），而throw catch finally机制常常被用来处理一些业务层面的自定义异常和错误
go语言中，panic和recover要慎用

panic

Go使用panic函数触发异常，它可以在任何地方引发
panic一般会导致程序挂掉（除非recover）然后Go运行时会打印出调用栈
即使函数执行的时候panic了，函数不往下走了，运行时并不是立刻向上传递panic，而是到defer那，等defer的东西都跑完了，panic再向上传递

func abc() {
panic("我是abc,我要抛出一个异常了，等下defer会通过recover捕获这个异常，然后正常处理，使后续程序正常运行。")
fmt.Println("我是PHP里panic后面要打印出的内容。")
}

abc中panic后的代码将不会执行

recover&defer

Go使用defer和recover处理和恢复异常
panic会在调用它的函数中向本层和它的所有上层逐级抛出，若一直没有recover将其捕获，程序退出后会产生crash；若在某层defer语句中被recover捕获，控制流程将进入到recover之后的语句中
必须要先声明defer，否则不能捕获到panic异常,也就是说要先注册函数，后面有异常了，才可以调用
defer 有点类似 try-catch-finally 中的 finally
可以在一个函数中执行多条defer语句，它们的执行顺序与声明顺序相反（堆栈，先进后出）
recover只有在defer调用的函数中有效
选择在一个合适的上游去recover，并打印堆栈信息，使得部署后的程序不会终止

func abc() {
defer func() {
if err := recover(); err != nil {
fmt.Println("终于捕获到了panic产生的异常：", err) // 这里的err就是panic传入的内容
fmt.Println("我是defer里的匿名函数，我捕获到panic的异常了，我要recover恢复过来          了。")
}
}() //注意这个()就是调用该匿名函数的
panic("我是abc,我要抛出一个异常了，等下defer会通过recover捕获这个异常，捕获到我时，在abc里是不会输出的，会在defer里被捕获输出，然后正常处理，使后续程序正常运行")
fmt.Println("我是panic后面要打印出的内容。但是我是永远也打印不出来了。因为逻辑并不会恢复到panic那个点去，函数还是会在defer之后返回，也就是说执行到defer后，程序直接返回到main()里，接下来开始执行cba()")
} 

func cba() {
fmt.Println("我是cba，如果没有defer来recover捕获panic的异常，我是不会被正常执行的。")
}

异常处理的正确姿势

在程序开发阶段，调用panic函数来中断程序的执行以强制发生异常，使得该异常不会被忽略，因而能够尽快被修复
在程序部署后，应恢复异常避免程序终止
在调用recover的延迟函数中以最合理的方式响应该异常：
打印堆栈的异常调用信息和关键的业务信息，以便这些问题保留可见
将异常转换为错误，以便调用者让程序恢复到健康状态并继续安全运行
对于不应该出现的分支，使用异常处理
针对入参不应该有问题的函数，使用panic设计
异常处理的作用域（场景）：
空指针引用
下标越界
除数为0
不应该出现的分支，比如default
输入不应该引起函数错误

Go语言错误和异常处理机制

错误和异常的区别

Go语言错误处理机制

error

错误处理的正确姿势

Go语言异常处理机制

panic

recover&defer

异常处理的正确姿势

猜你喜欢

热点阅读