Handling Panics in Go Routines
Go provides the panic() and recover() built-ins to manage unexpected errors and fatal conditions in running code. To handle panics in a go routine, it's essential to understand the scope of recover().
Understanding recover() Scope
recover() can only recover from panics within the same goroutine that raised the panic. If a panic occurs in a goroutine with no active recover(), the entire program will crash.
Example with Incorrect Error Handling
The provided code example in the question fails to handle a panic because recover() is defined in the main routine, while the panic is raised in the handle() goroutine. As a result, recover() cannot access the panic value.
func main() { // ... go handle(done) // ... } func handle(done chan int64) { // ... fmt.Println(*a) // Panic here done <- *a // Dereferencing nil pointer }
Example with Correct Error Handling
To handle panics raised in a goroutine, place the recover() within the goroutine itself.
func main() { // ... defer func() { if r := recover(); r != nil { fmt.Println("Recovered") } }() go handle(done) // ... } func handle(done chan int64) { // ... defer func() { if r := recover(); r != nil { fmt.Println("Recovered") } }() fmt.Println(*a) // Panic here done <- *a // Dereferencing nil pointer }
Explanation
In this corrected example, recover() is now within the handle() goroutine, so it can capture the panic raised by dereferencing the nil pointer. The panic is then recovered, and the "Recovered" message is printed.
Understanding the scope of recover() is crucial for effective error handling in Go routines. Always place recover() within the same goroutine where the panic could occur to gracefully handle and report any unexpected conditions.
The above is the detailed content of How to Handle Panics in Go Routines: Understanding Recover Scope?. For more information, please follow other related articles on the PHP Chinese website!