Golang中panic与recover的区别

目录前言流程关于recover前言与defer类似的是，goroutine 中也有一个_panic链表头指针指向一个_panic链，发生panic的时候也是在链表头插入_panic结构体（执行gopanic）

在执行过程中发生了panic。那么panic以后的代码不会执行，转而执行panic的逻辑，再执行defer，执行到的defer要将started标记为true，同时将其defer结构体中的_panic指针指向当前的_panic，表示这个defer是由该panic触发的。再去执行defer链表，如果defer执行中还触发了panic，panic后的代码不载执行，将这个panic插入panic链头，同时将其作为当前panic。当遇到了与当前panic不符的defer，就找到该defer上的panic，将其标记为已终止，从defer链表中移除当前执行的defer。打印panic移除信息，从链表尾开始逐步输出流程panic执行defer的流程：先标记started=true，_panic=&panic后释放目的是为了终止之前发生的panic

异常信息的输出方式：

所有还在panic链表上的项会被输出顺序与发生panic的顺序一致

// A _panic holds information about an active panic.

type _panic struct {// argp 存储当前要执行的defer的函数参数地址argp unsafe.Pointer // pointer to arguments of deferred call run during panic; cannot move - known to liblink// arg panic函数自己的参数arg interface{} // argument to panic// link，链到之前发生的panic link *_panic // link to earlier panic pc uintptr // where to return to in runtime if this panic is bypassed sp unsafe.Pointer // where to return to in runtime if this panic is bypassed// recovered 标识panic是否被恢复recovered bool // whether this panic is over// aborted 标识panic是否被终止aborted bool // the panic was aborted goexit bool}关于recover recover只执行一件事将当前执行的panic的recovered字段置为true在每个defer执行完以后panic处理流程都会检查当前panic是否被recover如果当前panic已经被恢复，就会将它从panic链中移除执行到的defer也会被移除，同时要保存_defer.sp和_defer.pc利用_defer.sp和_defer.pc跳出当前panic的处理流程，通过栈指针判断，只执行当前函数中注册的defer函数

在发生recover的函数正常结束后才会进入到检测panic是否被恢复的流程当recover的函数又发生panic时，goroutine会将该panic加入到链头，设置为当前panic，再去执行defer链表，发现当前defer是当前panic执行的，移除当前defer，继续执行下一个，直到发现不是当前panic执行的，在panic链上找到那个panic，输出异常信息对于已经recover标记的panic在输出异常信息时会加上recovered标记

到此这篇关于Golang中panic与recover的区别的文章就介绍到这了,更多相关Go panic recover内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:GO语言异常处理机制panic和recover分析golang 中 recover()的使用方法go语言异常panic和恢复recover用法实例go语言的panic和recover函数用法实例Go panic和recover函数使用细节深入探究Go中recover与panic区别详解Golang Recover处理错误原理解析Golang利用Recover进行错误处理golang recover函数使用中的一些坑解析go使用Cron定时实现recover机制