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 
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 
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.