panic and recover

Triggering a panic

Calling panic(value) immediately stops the current function's normal execution and begins unwinding the stack, running any deferred calls along the way, until either something recovers or the program crashes.

Example: Triggering a panic

package main

import "fmt"

func mustBePositive(n int) int {
	if n < 0 {
		panic("negative number not allowed")
	}
	return n
}

func main() {
	defer fmt.Println("this still runs during unwind")
	fmt.Println(mustBePositive(5))
}

Recovering from a panic

recover, called from within a deferred function, stops the panic from propagating further and returns the value passed to panic -- allowing the program to log the problem and keep running instead of crashing entirely.

Note: recover() only has an effect when called directly inside a deferred function.

Example: Recovering from a panic

package main

import "fmt"

func safeDivide(a, b int) (result int) {
	defer func() {
		if r := recover(); r != nil {
			fmt.Println("recovered from:", r)
			result = 0
		}
	}()
	return a / b
}

func main() {
	fmt.Println(safeDivide(10, 0))
	fmt.Println("program continues normally")
}

panic vs Returning an Error

Idiomatic Go reserves panic for programmer errors or truly unrecoverable situations (like a required invariant being violated), while ordinary, expected failure conditions -- a missing file, invalid input -- should be communicated through a returned error instead.

Note: If you find yourself panicking for something a caller might reasonably want to handle, return an error instead.

Example: panic vs Returning an Error

package main

import (
	"errors"
	"fmt"
)

func divide(a, b int) (int, error) {
	if b == 0 {
		return 0, errors.New("division by zero") // expected failure: use error
	}
	return a / b, nil
}

func main() {
	result, err := divide(10, 0)
	if err != nil {
		fmt.Println("handled gracefully:", err)
		return
	}
	fmt.Println(result)
}