panic и recover в Go: паники во время выполнения и когда паниковать

Как выглядит паника

Паника останавливает текущую функцию, выполняет её отложенные вызовы, затем делает то же в вызывающей функции и так далее вверх по стеку. Если она доходит до вершины горутины, программа падает.

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")
}

Программа завершается с кодом 2. Вывод:

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

Отложенный вызов выполнился до отчёта о падении. В трассировке указаны горутина, функция и строка, и обычно этого достаточно, чтобы найти баг.

Типичные паники во время выполнения

Каждый из этих случаев это баг в программе, а не ситуация, которую нужно обрабатывать. Исправление это проверка границ, проверка на nil, make или утверждение comma-ok, а не recover.

Восстановление

recover() останавливает панику. Он работает, только если вызван непосредственно внутри отложенной функции, потому что отложенные функции это единственный код, который выполняется во время раскрутки паники.

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")
}

Вывод:

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

Что произошло во втором вызове:

1. a / b запаниковало.
2. Выполнилось отложенное замыкание, и recover() вернул значение паники (runtime.Error).
3. Раскрутка остановилась. safeDivide нормально вернула управление в main, а именованный результат err установило замыкание.

Именно именованный результат позволяет отложенной функции вернуть ошибку. Без него функция возвращает свои нулевые значения. Как отложенные замыкания меняют результаты, разобрано на странице о defer.

recover() возвращает nil, когда паники нет, поэтому проверка if r != nil делает отложенную функцию безвредной на обычном пути. Вызванный вне отложенной функции или в функции, которую вызывает отложенная функция, recover возвращает nil и ничего не делает.

panic со своим значением

panic принимает любое значение. Обычно это ошибка или строка.

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))
}

Перехватывайте то, что ожидаете, а всё остальное паникуйте заново. Если глотать все паники, настоящие баги окажутся скрыты.

Начиная с Go 1.21 panic(nil) превращается в *runtime.PanicNilError, так что nil из recover() теперь надёжно означает «паники не было».

Паники в горутинах

recover перехватывает паники только в своей горутине. Паника в любой горутине без recover убивает весь процесс, включая main и все остальные горутины.

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")
}

Две строки воркеров могут напечататься в любом порядке; main finished всегда последняя. defer recover() в main не спас бы программу от второго воркера. Поэтому HTTP-серверы восстанавливаются на уровне запроса: net/http перехватывает паники в горутине каждого обработчика, логирует их и закрывает это соединение, так что один плохой запрос не роняет сервер.

Некоторые сбои это фатальные ошибки, а не паники, и восстановиться после них нельзя вовсе: concurrent map writes, нехватка памяти и сообщение детектора взаимных блокировок all goroutines are asleep.

Когда паника это правильное решение

Общее правило Go: возвращайте ошибки для всего, что может пойти не так во время выполнения, и паникуйте только из-за ошибок программиста. Конкретно паника уместна, когда:

• Нарушен инвариант. switch по вашему собственному перечислению попадает в вариант, который невозможен. Продолжение испортило бы данные.
• Помощник Must получил некорректный константный ввод. regexp.MustCompile, template.Must и uuid.MustParse оборачивают функцию, возвращающую ошибку, и паникуют при неудаче. Используйте их для значений, известных на этапе компиляции, обычно для переменных уровня пакета, где сбой означает, что неправилен исходный код:

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

• Запуск не может продолжаться. В main нет обязательной конфигурации. Даже здесь напечатать ошибку и вызвать os.Exit(1) часто аккуратнее, чем показывать трассировку стека.

Паника не подходит для:

• Ожидаемых сбоев: неверный пользовательский ввод, отсутствующий файл, таймаут. Возвращайте error; см. обработку ошибок.
• Управления потоком: panic и recover в роли исключений через большое дерево вызовов делают код трудным для понимания. Стандартная библиотека делает так внутри себя в паре мест (кодировщик encoding/json), но всегда восстанавливается до возврата, так что ни одна паника не покидает пакет.
• API библиотек: библиотека, которая паникует на плохом вводе, заставляет каждого вызывающего добавлять recover. Возвращайте ошибку.

Частые ошибки

• Вызов recover вне отложенной функции. Он возвращает nil.
• recover в main для паники в горутине. Каждой горутине нужен свой.
• Проглатывание всех паник. Логируйте со стеком (debug.Stack() из runtime/debug) и паникуйте заново то, чего не ожидали.
• recover для записи в nil-мапу или индекса за границами. Исправьте баг.