Panic i recover w Go: paniki runtime i kiedy panikować

Jak wygląda panika

Panika zatrzymuje bieżącą funkcję, wykonuje jej wywołania odroczone, a potem robi to samo w funkcji wywołującej i tak dalej w górę stosu. Jeśli dotrze na szczyt gorutyny, program się wywraca.

package main

import "fmt"

func main() {
	defer fmt.Println("deferred in main: still runs")

	nums := []int{1, 2, 3}
	i := 5
	fmt.Println("before")
	fmt.Println(nums[i]) // panics
	fmt.Println("never printed")
}

Ten program kończy się ze statusem 2. Wynik:

before
deferred in main: still runs
panic: runtime error: index out of range [5] with length 3

goroutine 1 [running]:
main.main()
	/tmp/main.go:11 +0x...
exit status 2

Wywołanie odroczone wykonało się przed raportem o awarii. Ślad stosu podaje gorutynę, funkcję i linię, co zwykle wystarcza, żeby znaleźć błąd.

Typowe paniki w czasie działania

Każda z nich to błąd w programie, a nie sytuacja do obsłużenia. Poprawką jest sprawdzenie zakresu, sprawdzenie nil, make albo asercja comma-ok, a nie recover.

Przechwytywanie

recover() zatrzymuje panikę. Działa tylko wywołane bezpośrednio wewnątrz funkcji odroczonej, bo funkcje odroczone to jedyny kod, który wykonuje się podczas zwijania stosu przez panikę.

package main

import "fmt"

func safeDivide(a, b int) (result int, err error) {
	defer func() {
		if r := recover(); r != nil {
			err = fmt.Errorf("recovered: %v", r)
		}
	}()
	return a / b, nil
}

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

Wynik:

5 <nil>
0 recovered: runtime error: integer divide by zero
program continues

Co się stało w drugim wywołaniu:

1. a / b wywołało panikę.
2. Wykonało się odroczone domknięcie, a recover() zwróciło wartość paniki (runtime.Error).
3. Zwijanie stosu się zatrzymało. safeDivide normalnie wróciło do main z nazwanym wynikiem err ustawionym przez domknięcie.

To nazwany wynik pozwala funkcji odroczonej oddać błąd. Bez niego funkcja zwraca swoje wartości zerowe. Strona o defer opisuje, jak odroczone domknięcia zmieniają wyniki.

recover() zwraca nil, gdy nie ma paniki, więc sprawdzenie if r != nil sprawia, że funkcja odroczona jest nieszkodliwa na normalnej ścieżce. Wywołane poza funkcją odroczoną albo w funkcji wywołanej przez funkcję odroczoną recover zwraca nil i nic nie robi.

panic z własną wartością

panic przyjmuje dowolną wartość. Typowo jest to błąd albo string.

package main

import (
	"errors"
	"fmt"
)

var ErrInvariant = errors.New("invariant violated")

func mustPositive(n int) int {
	if n <= 0 {
		panic(fmt.Errorf("mustPositive(%d): %w", n, ErrInvariant))
	}
	return n
}

func main() {
	defer func() {
		r := recover()
		if err, ok := r.(error); ok && errors.Is(err, ErrInvariant) {
			fmt.Println("caught:", err)
			return
		}
		if r != nil {
			panic(r) // not ours: re-panic
		}
	}()

	fmt.Println(mustPositive(3))
	fmt.Println(mustPositive(-1))
}

Przechwytuj to, czego się spodziewasz, a wszystko inne puszczaj dalej ponownym panic. Połykanie każdej paniki ukrywa prawdziwe błędy.

Od Go 1.21 panic(nil) zamienia się w *runtime.PanicNilError, więc nil zwrócone przez recover() teraz niezawodnie oznacza „brak paniki”.

Paniki w gorutynach

recover łapie paniki tylko we własnej gorutynie. Panika w dowolnej gorutynie bez recover zabija cały proces, łącznie z main i wszystkimi innymi gorutynami.

package main

import (
	"fmt"
	"sync"
)

func safeGo(wg *sync.WaitGroup, name string, f func()) {
	wg.Add(1)
	go func() {
		defer wg.Done()
		defer func() {
			if r := recover(); r != nil {
				fmt.Printf("worker %s panicked: %v\n", name, r)
			}
		}()
		f()
	}()
}

func main() {
	var wg sync.WaitGroup
	safeGo(&wg, "ok", func() { fmt.Println("worker ok done") })
	safeGo(&wg, "bad", func() {
		var m map[string]int
		m["x"] = 1
	})
	wg.Wait()
	fmt.Println("main finished")
}

Dwie linie workerów mogą pojawić się w dowolnej kolejności; main finished zawsze jest ostatnie. defer recover() w main nie uratowałoby programu przed drugim workerem. Dlatego serwery HTTP przechwytują paniki osobno dla każdego żądania: net/http przechwytuje paniki w gorutynie każdego handlera, loguje je i zamyka to połączenie, więc jedno złe żądanie nie kładzie serwera.

Niektóre awarie to błędy krytyczne, a nie paniki, i w ogóle nie da się ich przechwycić: concurrent map writes, brak pamięci i all goroutines are asleep z detektora zakleszczeń.

Kiedy panika jest właściwym wyborem

Ogólna zasada Go: dla wszystkiego, co może pójść źle w czasie działania, zwracaj błędy, a panikuj tylko przy pomyłkach programisty. Konkretnie panika jest na miejscu, gdy:

• Złamany jest niezmiennik. switch po twoim własnym enumie trafia na przypadek, który nie może się zdarzyć. Kontynuowanie uszkodziłoby dane.
• Funkcja pomocnicza Must dostaje złą stałą. regexp.MustCompile, template.Must i uuid.MustParse opakowują funkcję zwracającą błąd i wywołują panikę przy niepowodzeniu. Używaj ich dla wartości znanych w czasie kompilacji, zwykle zmiennych na poziomie pakietu, gdzie niepowodzenie oznacza, że błędny jest kod źródłowy:

var emailRE = regexp.MustCompile(`^[^@\s]+@[^@\s]+$`)

• Start nie może być kontynuowany. Brak wymaganej konfiguracji w main. Nawet tu wypisanie błędu i wywołanie os.Exit(1) jest często czystsze niż ślad stosu.

Panika to złe narzędzie do:

• Spodziewanych niepowodzeń: niepoprawne dane od użytkownika, brakujący plik, timeout. Zwróć error; zobacz obsługę błędów.
• Sterowania przepływem: używanie panic i recover jak wyjątków w dużym drzewie wywołań sprawia, że kod trudno śledzić. Biblioteka standardowa robi tak wewnętrznie w kilku miejscach (enkoder encoding/json), zawsze przechwytując panikę przed powrotem, więc żadna panika nie wychodzi poza pakiet.
• API bibliotek: biblioteka, która panikuje przy złych danych, zmusza każdego wywołującego do dodawania recover. Zwróć błąd.

Częste błędy

• Wywołanie recover poza funkcją odroczoną. Zwraca nil.
• Przechwytywanie w main paniki z gorutyny. Każda gorutyna potrzebuje własnego recover.
• Połykanie wszystkich panik. Loguj je ze stosem (debug.Stack() z runtime/debug) i ponownie wywołuj panikę dla tego, czego się nie spodziewasz.
• Używanie recover do obsługi zapisów do mapy nil albo indeksów poza zakresem. Zamiast tego popraw błąd.