Golang异常处理之优雅地控制和处理异常
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")
}
输出结果:
c
a
d
异常信息
e
注意
- 利用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后面的代码不会执行
subFun
recovered
子协程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= 4
recovered2
subFun,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 +0x89
created 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异常处理内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网!
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341