Краткий ответ

Нет. После успешного вызова recover текущая паника считается перехваченной, поэтому последующие deferred-обработчики не смогут получить её повторно: их вызов recover вернёт nil. Значение паники нужно сохранить или передать внутри того обработчика, который выполнил восстановление.

Исторический контекст

В Go паника предназначена для аварийного прекращения обычного выполнения, а recover — для восстановления на заранее выбранной границе, например в middleware или на границе горутины. Такая модель позволяет не проверять исключительную ситуацию после каждого вызова, но сохраняет явный контроль над местом, где паника превращается в обычный результат или логируется.

Механизм рассчитан на единичное восстановление одной последовательности раскрутки стека. Он не является способом многократно читать или распространять одно значение паники между независимыми обработчиками.

Постановка проблемы

У функции может быть несколько defer: один отвечает за восстановление, другой — за метрики, третий — за освобождение ресурса. Ошибочно ожидать, что каждый из них сможет вызвать recover и получить исходное значение паники.

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

Подробное решение

При панике Go начинает выполнять deferred-функции в обратном порядке их регистрации. Пока паника активна, вызов recover из непосредственно выполняемой deferred-функции возвращает значение, переданное в panic, и прекращает раскрутку.

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

package main

import "fmt"

func main() {
	defer func() { fmt.Println("outer:", recover()) }()
	defer func() {
		fmt.Println("inner:", recover())
		fmt.Println("again:", recover())
	}()
	panic("boom")
}

Сначала сработает inner: первый recover напечатает boom, второй — nil. Затем выполнится outer, где recover также вернёт nil; после завершения deferred-функций main продолжит завершение без повторной паники.

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

Важно, что recover не превращает панику автоматически в error. Обработчик должен сам проверить значение, выбрать политику и не скрыть неожиданный сбой без логирования или другого контроля.

Ситуация из практики

В HTTP middleware есть deferred-обработчик восстановления паник и отдельный обработчик аудита, который тоже пытается вызвать recover, чтобы записать причину. Если аудит зарегистрирован так, что выполняется первым, он перехватит панику, а middleware уже не сможет получить её значение. Если первым выполняется middleware, аудит увидит nil.

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

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

Что кандидаты часто упускают

1. Что вернёт recover, если первый вызов получил значение, но обработчик продолжил работу?

Все последующие вызовы recover для этой паники вернут nil. Первый успешный вызов завершает активную фазу паники; он не создаёт объект, который можно повторно извлекать.

2. Могут ли deferred-функции после успешного восстановления продолжить выполняться?

Да. Уже зарегистрированные deferred-функции продолжают выполняться в обратном порядке. Но они выполняются уже без активной паники, поэтому их recover не получит исходное значение.

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

3. Как сохранить исходную панику, если после восстановления нужно снова аварийно завершить выполнение?

Нужно присвоить результат recover локальной переменной, выполнить логирование или преобразование, а затем явно вызвать panic с сохранённым значением. Такая повторная паника уже является новой операцией; другие deferred-функции могут увидеть её при новой раскрутке, однако повторно получить первоначальную панику через recover нельзя.

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