上个星期的文章说明了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成功。
如上图所示，panic和recover之间必须隔着一层函数调用，没有这层函数调用，或是大于一层的函数调用，recover都会失败。
今天的课就到这里结束了，本节课分析了recover的失败的两个问题：
1、是不在同一个groutine的recover会失败
2、recover和最上层的函数调用，中间必须隔着且仅仅是一层函数调用，不然也会失败！
下课！
