panic и recover в Go

Где место panic

Рантайм паникует сам, когда программа делает невозможное: выход за границы слайса, разыменование nil-указателя, деление на ноль, запись в nil-мапу. Это сигнал об ошибке в коде, а не о плохом вводе.

Программисту panic уместен ровно в двух местах. Первое - при инициализации, когда без чего-то работать нельзя: не разобрался конфиг, не скомпилировался обязательный шаблон, не подключилась база на старте. Падать при запуске лучше, чем работать наполовину; на этом и построены функции с суффиксом Must - MustCompile, MustParse.

Второе - нарушение внутреннего инварианта библиотеки, до которого не должно доходить в принципе. Если пользователь вызвал метод в состоянии, которого по контракту не бывает, паника честнее тихой порчи данных.

// Чего panic делать не должен: обрабатывать плохой пользовательский ввод, отсутствующую запись в базе, обрыв сети. Это ожидаемые события, для них есть error. Паника, вылезающая из публичного API пакета на нормальном вводе, - дефект пакета.

Как работает recover

При панике исполнение функции прекращается, но отложенные вызовы выполняются - на этом всё и держится. Если внутри отложенной функции позвать recover, паника останавливается, она возвращает переданное в panic значение, и функция завершается нормально.

Условие жёсткое: recover обязан быть вызван непосредственно в теле отложенной функции. Проверено: если вынести его во вспомогательную функцию, вызванную из отложенной, recover вернёт nil, и процесс упадёт как ни в чём не бывало. Отладка такого случая занимает вечер, если не знать правила.

Второе ограничение важнее первого: recover ловит панику только своей горутины. Никакой перехват в main не спасёт от паники в запущенной горутине - проверено, процесс падает целиком с трассировкой той горутины, где рвануло.

// Отсюда практика: у каждой горутины, обрабатывающей внешние данные, свой defer с recover внутри неё самой. Одно необработанное сообщение из очереди не должно ронять весь сервис.

defer func() { fmt.Println("поймали:", recover()) }()   // работает

// а так - НЕ работает:
helper := func() { fmt.Println(recover()) }            // вернёт nil
defer func() { helper() }()
// паника пойдёт дальше и уронит процесс

Перехватили, и что дальше

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

Разумный сценарий один: остановить текущую единицу работы, записать в лог значение паники и стек через debug.Stack, вернуть наверх обычную ошибку. Именно так устроен веб-фреймворк с восстановлением: паника в обработчике превращается в пятисотый ответ, а сервер продолжает жить.

Отдельно про границу пакета. Библиотека может использовать panic внутри себя как быстрый выход из глубокой рекурсии, но обязана перехватить его на границе и вернуть пользователю обычную ошибку. Паника, вылетевшая наружу, - нарушение контракта.

// И маленькая, но важная деталь: паникуй значениями ошибок, а не строками. panic(fmt.Errorf(...)) даёт recover типизированное значение, с которым можно работать, а panic("что-то сломалось") - только текст.

debug.Stack

возвращает стек текущей горутины строкой; главное, что нужно записать при перехвате паники

Как отвечать: «Когда уместен panic и где сработает recover?»

panic уместен там, где продолжать бессмысленно, потому что нарушен инвариант программы. Практически это два места: инициализация, когда без ресурса работать нельзя - отсюда функции с Must вроде regexp.MustCompile, - и нарушение внутреннего контракта библиотеки, до которого не должно доходить. Ожидаемые события - плохой ввод, отсутствие записи, обрыв сети - это error, а не паника. Про recover два правила, и оба легко проверить. Первое: он обязан вызываться непосредственно в теле отложенной функции. Если спрятать его во вспомогательную функцию, вызванную из defer, он вернёт nil и паника пойдёт дальше - я на это натыкался. Второе, более важное: recover ловит панику только своей горутины. Перехват в main не спасёт от паники в запущенной горутине, процесс упадёт целиком. Поэтому у каждой горутины, обрабатывающей внешние данные, свой defer с recover. И перехват для меня не означает «всё в порядке»: я останавливаю текущую единицу работы, пишу в лог значение и стек через debug.Stack и возвращаю наверх обычную ошибку.

Зона применения очерчена двумя конкретными случаями, названы оба ограничения recover с проверкой, и показано, что перехват - это переход к штатной обработке, а не игнорирование.

На чём валят

• −Используют panic вместо error для плохого ввода и сетевых сбоев.
• −Зовут recover не напрямую в defer, а во вложенной функции - он возвращает nil.
• −Рассчитывают перехватить в main панику из горутины - процесс падает целиком.
• −Перехватывают панику и продолжают работу, будто ничего не случилось.
• −Выпускают панику наружу из публичного API пакета.
• −Паникуют строкой вместо значения ошибки и теряют возможность разобрать причину.