defer, panic и recover в Go: три момента вместо одного и recover, который молча не работает

Что здесь на самом деле спрашивают

Лестница почти всегда такая:

1. «Когда выполняется отложенный вызов?» — разминка, отвечают все.
2. «А когда вычисляются его аргументы?» (с кодом) — здесь отваливается половина.
3. «В каком порядке?» и сразу за ним «что будет с defer в цикле?»
4. «Может ли отложенная функция изменить возвращаемое значение?» — вопрос про именованные результаты.
5. «Что recover не поймает?» — проверяют, знаете ли вы про «непосредственно в отложенной функции» и про чужую горутину.
6. «defer дорогой?» — вопрос на честность: без числа обе крайности одинаково плохи.

Дальше урок идёт по этой лестнице. Спина у неё одна: у отложенного вызова три момента, а не один.

База: три правила отложенного вызова и одно про панику

Прежде чем разбирать механизм, стоит назвать обычными словами то, из чего он весь состоит. У defer три правила, и все три — про время.

Первое: отложенный вызов записывают сейчас, а выполняют при выходе из функции. Строка defer f() сама ничего не вызывает. Она говорит: «когда эта функция будет заканчиваться, позови f()». Заканчиваться — значит доходить до возврата любым путём, в том числе через ошибку. Отсюда и польза: закрытие стоит рядом с открытием, и забыть его нельзя, сколько бы return в функции ни было.

Второе: аргументы отложенного вызова вычисляются в момент записи, а не в момент выполнения. defer f(i) запоминает не переменную i, а её значение — то, какое было на этой строке. Изменится i потом — отложенный вызов об этом не узнает. Это единственное место темы, где код читается не так, как выполняется, и именно на нём чаще всего ошибаются.

Третье: несколько отложенных вызовов выполняются в обратном порядке. Записали три — выполнятся третий, второй, первый. Это ровно то, что нужно для парных операций: что захвачено последним, освобождается первым.

Теперь про панику. Паника не обрывает программу на месте — она разворачивает стек: идёт от места сбоя вверх по вызовам и на каждом уровне по дороге выполняет отложенные вызовы этого уровня. Поэтому defer надёжен и при панике: файл закроется, мьютекс освободится.

И отсюда же ограничение, из которого растёт половина вопросов на собеседовании: перехватить панику можно только из отложенного вызова. Больше неоткуда — во время разворачивания выполняются только они; обычный код кадра к этому моменту уже позади.

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

Механизм 1: одна временная шкала на три механизма

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

Дальше урок проходит по этой шкале сверху вниз. Всё, что кажется в теме странным, — это следствие того, где на ней стоит та или иная точка.

Начнём с трёх моментов у самого defer:

1. Регистрация — в момент выполнения строки с defer.
2. Вычисление аргументов — тогда же, в момент регистрации.
3. Выполнение — непосредственно перед возвратом из функции.

Второй пункт — это и есть вся разница между «знаю правило» и «знаю механизм». Спецификация формулирует его прямо:

Переключайте сценарии и шаги — на каждом видно, какой из трёх моментов наступил:

Отсюда сразу три вывода, и каждый спрашивают отдельно.

Аргументы уже сняты. defer fmt.Println(i) печатает то значение, которое i имело на строке с defer. Хотите позднее чтение — заверните: defer func() { fmt.Println(i) }(). Внутри литерала i читается в момент выполнения.

Получатель метода — тоже аргумент. defer mu.Unlock() снимает mu сразу, и если переменную переприсвоят, отложенный вызов пойдёт к старому объекту.

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

Механизм 2: defer в цикле — вопрос не цены, а срока

Классический вопрос «найдите ошибку», и код обычно такой:

func process(names []string) error {
    for _, name := range names {
        f, err := os.Open(name)
        if err != nil {
            return err
        }
        defer f.Close()      // ЛОВУШКА
        // …работа с f…
    }
    return nil
}

Ошибка не в том, что это медленно. Ошибка в том, что f.Close() выполнится на выходе из process, а не из витка. На тысяче файлов открытыми будут все тысяча одновременно — и на каком-то из них программа упрётся в предел дескрипторов.

Лечится выделением тела витка в функцию:

for _, name := range names {
    if err := handle(name); err != nil {   // defer внутри handle
        return err
    }
}

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

Механизм 3: изменить результат может только именованный

Вопрос звучит как «может ли defer повлиять на возвращаемое значение», и правильный ответ — «да, если результат именован». Механизм такой: return x — это не одно действие, а два. Сначала результату присваивается x, потом выполняются отложенные вызовы, и только потом управление уходит вызывающему.

func named() (result int) {
    defer func() { result *= 2 }()
    return 1              // вернёт 2
}
 
func anon() int {
    result := 1
    defer func() { result *= 2 }()
    return result         // вернёт 1
}

Разница не в стиле. В первом случае отложенная функция замыкается на сам результат; во втором — на локальную переменную, значение которой уже скопировано в результат.

Где это применяют на практике. Ровно в двух местах, и оба стоит назвать:

// 1. Превратить панику в ошибку на границе пакета.
func Parse(b []byte) (v Value, err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("parse: %v", r)
        }
    }()
    return parseFast(b), nil
}
 
// 2. Обернуть ошибку контекстом, не трогая каждый return.
func load(name string) (err error) {
    defer func() {
        if err != nil {
            err = fmt.Errorf("load %s: %w", name, err)
        }
    }()
    // …десяток return err…
}

Оба приёма работают только с именованным результатом — и оба перестают работать молча, если имя убрать.

Механизм 4: паника — это раскрутка стека

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

panic(v) не обрывает программу на месте. Он запускает раскрутку стека, и на каждом кадре по дороге вверх происходит одно и то же:

Три вещи следуют отсюда прямо, и все три спрашивают.

Отложенные вызовы выполняются при панике. Это не «аварийный выход» — это тот же момент 3 со шкалы первого механизма. Именно поэтому defer f.Close() надёжен: файл закроется и при панике тоже.

Перехват возможен только на кадре, который ещё не раскручен. Раскрутка идёт снизу вверх, и recover в кадре decode работает, а в кадре, который уже пройден, — нет. Кадров ниже места паники к этому моменту уже не существует.

Если никто не перехватил, раскрутка доходит до верха горутины — и процесс завершается с трассировкой. Не «падает случайно»: доходит до конца по вполне определённому пути.

Чего recover не ловит

Здесь три ответа, и каждый спрашивают отдельно.

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

Проверено запуском:

Вторая строка — это тот самый рефакторинг «вынесем перехват в общий хелпер». Он компилируется, проходит ревью и отключает перехват.

Второе — паника другой горутины. У каждой горутины свой стек отложенных вызовов, и снаружи её поймать нельзя: recover в вызывающем коде не увидит ничего, а процесс умрёт. Спецификация говорит про «паникующую горутину», и слово выбрано точно. Отсюда практическое правило: у каждой горутины, которую вы запускаете, должен быть свой перехват, если её падение не должно ронять процесс.

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("worker: %v", r)
        }
    }()
    work()
}()

Третье — fatal error рантайма. Одновременная запись в карту, дедлок всех горутин, исчерпание памяти — это не паника. Стек не разматывается, отложенные вызовы не выполняются, recover не вызывается вовсе.

И отдельно про panic(nil): с Go 1.21 он превращается в *runtime.PanicNilError. До этого recover() возвращал nil, проверка if r := recover(); r != nil не срабатывала, и функция продолжала работу после паники — молча и с неверным результатом.

Механизм 5: паника — не способ вернуть ошибку

Отдельный вопрос, который задают под конец и который отделяет тех, кто писал на Go в проде.

Ошибка — это ожидаемый исход, часть контракта функции: файла нет, сеть недоступна, ввод некорректен. Такое возвращают значением, и вызывающий решает, что делать.

Паника — это нарушенный инвариант, то есть состояние, из которого продолжать нельзя и о котором вызывающему сообщать бессмысленно: индекс вне границ, разыменование nil, невозможная ветка switch. Стандартная библиотека паникует ровно в таких местах.

Отсюда практическая граница, и она проверяемая:

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

И одно правило про границы. Паника не должна пересекать границу пакета: если внутри для удобства используется паника, на выходе её перехватывают и превращают в error. Так устроен, например, разбор в encoding/json.

Глубже: что это стоит

Числа — из прогона bench/godefer/internals.go, чередующимися кругами.

У defer две разные цены, и в исходнике это одно и то же слово:

Первая строка — «открытый» defer: с Go 1.14 компилятор разворачивает его в обычный код на выходе из функции. Цикл этого не позволяет — число отложенных вызовов заранее неизвестно, и каждый приходится регистрировать в списке.

Важная поправка к расхожему. Выделений в куче нет ни в одном случае — запись об отложенном вызове кладётся на стек. Утверждение «defer в цикле выделяет память» повторяют часто, и замер его не подтверждает.

На самом частом применении разница ещё меньше:

Паника — другой разговор:

Важнее не четвёртая строка, а третья: форма с перехватом стоит дороже даже тогда, когда паники не случилось. Цену платит каждый вызов, а не только сбойный.

И у четвёртой строки надо назвать границу, иначе она превращается в закон. 122 — это отношение двух пустых функций на одной машине и одной версии Go: кроме самой формы возврата в них нет никакой работы, поэтому кратность здесь верхняя, а не типичная. Стоит добавить в обе функции хоть что-нибудь полезное — и она уменьшится, потому что уменьшается доля механики возврата в общем времени.

Поэтому правило пишется не от числа. Не «паника в сто раз дороже ошибки», а: паникой не возвращают ожидаемый сбой — по причине, которая названа механизмом 5 и от замера не зависит вовсе. Кратность нужна ровно для одного: понять, что цена не в единицах процентов, и не пытаться выиграть на выборе между error и паникой там, где выбор определяется смыслом.

Как отвечать на собеседовании

Короткий ответ: у отложенного вызова три момента, а не один. Регистрация и вычисление аргументов — в момент defer, выполнение — при выходе из функции; а если отложенных вызовов несколько, они идут в обратном порядке. Паника разворачивает стек, выполняя по дороге отложенные вызовы каждого кадра, и перехватить её можно только вызовом recover непосредственно в отложенной функции.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

На «когда выполняется» отвечайте тремя моментами. «Регистрация и вычисление аргументов — в момент defer, выполнение — перед возвратом». Второй пункт сразу отделяет знающего механизм.

Про цикл говорите про срок, а не про скорость. «Сработает на выходе из функции, а не из витка; на тысяче файлов будет тысяча открытых дескрипторов». Ответ «это медленно» — не тот, которого ждут.

Про изменение результата назовите два действия return. «Сначала присваивание результату, потом отложенные вызовы; поэтому именованный результат изменить можно, а неименованный — нет».

Про recover процитируйте скобки. «Только непосредственно в отложенной функции — не в вызванной из неё». И добавьте два случая, которые он не ловит: чужая горутина и fatal error.

Про цену дайте два числа и разделите их. «Открытый defer — единицы наносекунд и ноль выделений; в цикле — десятки на виток. Паника против возврата ошибки — два порядка». Одно число без другого превращает верный замер в неверное правило.

Дальше спросят

func write(name string) (err error) {
    f, err := os.Create(name)
    if err != nil {
        return err
    }
    defer func() {
        if cerr := f.Close(); cerr != nil && err == nil {
            err = cerr
        }
    }()
    // …запись…
}

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

	i := 0
defer fmt.Println(i)
i = 42
fmt.Println(i)

for n := 1; n <= 3; n++ {
	defer fmt.Println(n)
}

func namedResult() (result int) {
defer func() { result *= 2 }()
return 1
}

func anonResult() int {
result := 1
defer func() { result *= 2 }()
return result
}

42
0
3
2
1
2
1
boom

0
42
1
2
3
2
1
boom

42
42
3
2
1
1
1
boom

42
0
1
2
3
2
2
boom

Проверка знаний