panic和recover使用
Go语言不支持传统的 try…catch…finally 这种异常，因为Go语言的设计者们认为，将异常与控制结构混在一起会很容易使得代码变得混乱。在Go语言中，设计者们推荐使用多值返回来返回错误。遇到真正的异常的情况下（比如除数为 0了）。才使用Go中引入的Exception处理：defer, panic, recover。
这几个异常的使用场景可以这么简单描述：Go中可以抛出一个panic的异常，然后在defer中通过recover捕获这个异常，然后正常处理
使用示例
- package main
- import "fmt"
- func main(){
- fmt.Println("c")
- defer func(){ // 必须要先声明defer，否则不能捕获到panic异常
- fmt.Println("d")
- if err:=recover();err!=nil{
- fmt.Println(err) // 这里的err其实就是panic传入的内容，55
- }
- fmt.Println("e")
- }()
- f() //开始调用f
- fmt.Println("f") //这里开始下面代码不会再执行
- }
- func f(){
- fmt.Println("a")
- panic("异常信息")
- fmt.Println("b") //这里开始下面代码不会再执行
- fmt.Println("f")
- }
输出结果： 注意
- 利用recover处理panic指令，recover需要定义在defer匿名函数内
- defer需要在panic之前声明，否则当panic时，recover无法捕获到panic
- panic无recover情况下，程序会直接崩溃
子函数panic主函数recover
- func TestPanic(t *testing.T) {
- defer func() {
- if err := recover(); err != nil {
- println("recovered")
- }
- }()
- subFun()
- subFun()
- }
- func subFun() {
- println("subFun")
- panic("subFun panic")
- }
输出结果如下，第一个sunFun后面的代码不会执行 子协程panic主函数recover
- func subFun(i int) {
- fmt.Println("subFun,i=", i)
- panic("subFun panic")
- }
- func TestSubGoPanic(t *testing.T) {
- defer func() {
- if err := recover(); err != nil {
- println("recovered2")
- }
- }()
- go subFun(3)
- subFun(4)
- println("finish")
- }
- 结果subFun,i= 4recovered2subFun,i= 3--- PASS: TestSubGoPanic (0.00s)panic: subFun panic
- goroutine 21 [running]:zh.com/base/err.subFun(0x0?) /Users/albert/file/code/go/zh/gotest/base/err/panic_test.go:34 +0x89created by zh.com/base/err.TestSubGoPanic /Users/albert/file/code/go/zh/gotest/base/err/panic_test.go:43 +0x46
recover会执行，但是程序崩溃了
使用总结
如果 panic 和 recover 发生在同一个协程，那么 recover 是可以捕获的，如果 panic 和 recover 发生在不同的协程，那么 recover 是不可以捕获的
也就是哪个协程有panic，哪个协程里必须要有recover，否则会把整个程序弄崩溃
使用panic的几点担心
性能
在使用 Golang 进行开发时，遇到 panic 是非常常见的情况。但是，panic 对于性能的影响是相对较小的，尤其是在实际使用中。
首先，Golang 在运行时会维护一个 panic 堆，用于存储栈中的 panic 对象。当程序遇到 panic 时，会将该 panic 对象添加到 panic 堆中。panic 堆的大小是有限的，如果堆中的对象过多，可能会导致 panic 堆溢出，从而影响程序的性能
性能对比
- func BenchmarkSubFunWithError(b *testing.B) {
- for i := 0; i < b.N; i++ {
- go subFunWithError(i)
- }
- }
- func BenchmarkSubFunWithRecover(b *testing.B) {
- for i := 0; i < b.N; i++ {
- go subFunWithRecover(i)
- }
- }
- func subFunWithRecover(i int) {
- //fmt.Println("subFun,i=", i)
- defer func() {
- if error := recover(); error != nil {
- //println("subFunWithRecover_recovered")
- }
- }()
- time.Sleep(time.Second)
- panic("subFun panic")
- }
- func subFunWithError(i int) error {
- //fmt.Println("subFun,i=", i)
- time.Sleep(time.Second)
- return errors.New("subFunWithError")
- }
- BenchmarkSubFunWithError-12 673920 1992 ns/op 489 B/op 3 allocs/op
- BenchmarkSubFunWithRecover-12 1000000 1229 ns/op 240 B/op 2 allocs/op
反而使用panic的性能更好？
安全
另外一个比较担心的点是panic容易导致崩溃，但是如上所示，只要main方法里做好recover，每个go协程使用封装好的带recover的方法来调用，其实并不会有问题
到此这篇关于Golang异常控制处理程序错误流程的文章就介绍到这了,更多相关Golang异常控制内容请搜索晓枫资讯以前的文章或继续浏览下面的相关文章希望大家以后多多支持晓枫资讯！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ | 
发表于 2023-5-2 16:06:26