22 | panic函数、recover函数以及defer语句（下）

从语言设计上，不使用try-catch而是用defer-recover有什么优势？c++和java作为先驱都使用try-catch，也比较清晰，为什么go作为新语言却要发明一个这样的新语法？有何设计上的考量？

如果defer中引发panic，那么在该段defer函数之前，需要另外一个defer来捕获该panic，并且代码中最后一个panic会被抛弃，由defer中的panic来成为最后的异常返回。

我感觉还是go的这种设计好用，它会强迫开发者区别对待错误和异常，并做出不同的处理。相比try{}catch，我在开发中经常看到开发者把大段大段的代码或者整个处理写到try{}中，这本身就是对try{}catch的乱用

//测试场景1 func Test() { defer func() { if errRecover := recover(); errRecover != nil { fmt.Println("recover2...") } fmt.Println("no recover2...") }() defer func() { test01() // test01()方法在defer func(){}中执行 }() b := 0 a := 1 / b fmt.Println(a) return } func test01() { if e := recover(); e != nil { fmt.Println("recover...") } else { fmt.Println("no recover...") } fmt.Println("defer exe...") } func main() { Test() } //输出： no recover... defer exe... recover2... no recover2... //测试场景2 func Test() { defer func() { if errRecover := recover(); errRecover != nil { fmt.Println("recover2...") } fmt.Println("no recover2...") }() defer test01() //test01()直接放到defer后面 b := 0 a := 1 / b fmt.Println(a) return } func test01() { if e := recover(); e != nil { fmt.Println("recover...") } else { fmt.Println("no recover...") } fmt.Println("defer exe...") } func main() { Test() } //输出： recover... defer exe... no recover2... 我的问题是：为什么场景1中出现panic没有在defer func() { test01() }()中被recover，而在defer func() { if errRecover := recover(); errRecover != nil { fmt.Println("recover2...") } fmt.Println("no recover2...") }()中被recover。 场景2使用defer test01 的写法后就可以被recover。

试验了一下在 goroutine 里面 panic，其他的 goroutine（比如main）是 recover()不到的： func main() { fmt.Println("start") defer func() { if p := recover(); p != nil { fmt.Println(p) } }() var wg sync.WaitGroup wg.Add(1) go func() { defer func() { wg.Done() }() panic(errors.New("panic in goroutine")) }() wg.Wait() }

iava世界里曾经try catch满天飞，现在还能看到不少这种代码，但逐渐大家认同了在去掉这种代码。 因为大部分catch住异常以后只是打个log再重新throw，这个交给框架代码在最外层catch住以后统一处理即可。非框架代码极少需要处理异常。 go世界里，err guard满天飞，但大部分的处理也是层层上传。但做不到不用，因为不像try那样去掉catch后会自动往上传递，不检查err的话就丢失了，所以这种代码去不掉。只能继续满天飞。 底层实现其实都是setjmp，主要的区别之一我认为是go设计者认为java异常的性能代价大。

可以 defer 有点类似java中的final语句，里面还可以抛出异常。这样的好处是，我们捕获panic之后，可以对起内容进行查看，如果不是我们关注的panic那么可以继续抛出去

老师，您好，我想问一下，如果在main函数里调用一个我自定义的panic方法，recover可以恢复；但是如果我将自定义的panic方法改为go mypanic这样，recover就不能恢复。这是什么原因呢？下面是我实验的代码 ==============可以恢复的============== package main import ( "errors" "fmt" ) func myRecover() { if err := recover(); err != nil { fmt.Printf("panic is %s", err) } } func myPanic() { panic(errors.New("自定义异常")) } func main() { defer myRecover() myPanic() } =================不可以恢复的============== package main import ( "errors" "fmt" "time" ) func myRecover() { if err := recover(); err != nil { fmt.Printf("panic is %s", err) } } func myPanic() { panic(errors.New("自定义异常")) } func main() { defer myRecover() go myPanic() time.Sleep(time.Second * 5) }

「延迟到什么时候呢？这要延迟到该语句所在的函数即将执行结束的那一刻，无论结束执行的原因是什么。」 以该节课中代码为例的话是要吃到main函数快结束时执行是吗？执行defer函数。

这个问题就引发了另一个问题。defer可以在同一个函数中嵌套使用吗？感觉这两个问题答案应该一致