上个星期的文章说明了recover的一个问题,不过当时给下的结论是因为defer的问题,今天特此再发一篇文章,算是勘误了。
重新回顾下上回的问题:
func main() {
recoverMode4()
}
func recoverMode1() {
defer func() { // 有效的捕获
if r := recover();r != nil{
fmt.Println(r)
}
}()
panic("this is a panic!")
}
func recoverMode2() {
defer MyRecover() // 有效的捕获
panic("this is a panic!")
}
func recoverMode3() {
defer MyRecover() // 无效的捕获
go func() {
panic("this is a panic!")
}()
}
func recoverMode4() {
defer MyRecover2() // 无效的捕获
panic("this is a panic!")
}
func MyRecover() {
if r := recover();r != nil{
fmt.Println(r)
}
}
func MyRecover2() {
func() {
if r := recover();r != nil{
fmt.Println(r)
}
}()
}
上面的代码分别展示了四中recover的类型,第一种是我们平常使用的,也是正常的方法,是能捕获成功的;第二种其实和第一种没有太大的区别,它的出现是为了引出第四种,和第四种相对应;第三种是不会捕获成功的,这里展示了recover了第一个知识点:不能捕获不在同一个groutine内发生的panic;第四种和第二种方法相对应,但是他也无法捕获成功,应为其中的函数调用栈的原因。下面从recover的源码角度分析,看看究竟:
func gorecover(argp uintptr) interface{} {
// Must be in a function running as part of a deferred call during the panic.
// Must be called from the topmost function of the call
// (the function used in the defer statement).
// p.argp is the argument pointer of that topmost deferred function call.
// Compare against argp reported by caller.
// If they match, the caller is the one who can recover.
gp := getg()
p := gp._panic
if p != nil && !p.goexit && !p.recovered && argp == uintptr(p.argp) {
p.recovered = true
return p.arg
}
return nil
上面的就是recover的源码,代码很简单,首先是getg,这个就是获取获取当期那groutine,这也就解释了上面的第三个判断为啥没办法捕获成功的原因,最后就是几个简单的判断,不过这几个简单的判断却是学问很大的。前三个判断都很好理解,分别判断了是否产生panic,当前函数是否已经退出和是否已经被修复。最后一个是当前参数和当前groutine的函数指针的判断,这个判断解释了上面的第四个问题,其中参数p.argp是当期最上层函数调用defer的函数指针,argp是调用recover的函数指针,在函数调用上,若是上面的第四种方法,p.argp指向的是MyRecover2函数内的func,注意这里并不是MyRecover2,argp指向的是recoverMode4。这两者不想等,无法recover成功。
recover 正确与错误的展示如上图所示,panic和recover之间必须隔着一层函数调用,没有这层函数调用,或是大于一层的函数调用,recover都会失败。
今天的课就到这里结束了,本节课分析了recover的失败的两个问题:
1、是不在同一个groutine的recover会失败
2、recover和最上层的函数调用,中间必须隔着且仅仅是一层函数调用,不然也会失败!
下课!
网友评论