4.2panic vs error

Отделим ожидаемые ошибки от нарушений инварианта и проследим, где recover способен восстановить управление.

Что происходит внутри рантайма

Компилятор превращает panic в обычный вызов функции runtime.gopanic. Она кладёт в стек текущей горутины структуру runtime._panic (значение, флаги, указатель на предыдущую панику) и цепляет её к полю gp._panic у g, дескриптора горутины. У каждой горутины свой g, поэтому паника раскручивает только её стек, и recover в другой горутине её не увидит. Обычный поток управления на этом заканчивается: дальше работает только раскрутка.

Раскрутка идёт по цепочке отложенных вызовов. У каждой горутины есть односвязный список gp._defer, куда попадают defer. Но большую часть из них компилятор (Go 1.14+) в список не кладёт вовсе: если defer стоит не в цикле и их в функции немного (до восьми), вызов вшивается прямо в эпилог - это open-coded defers. Рантайм при панике находит такие вызовы по funcdata-записи самой функции abi.FUNCDATA_OpenCodedDeferInfo. Поэтому defer в Go стоит порядка одной наносекунды в happy path и «дорожает» только в момент паники.

Дальше рантайм идёт кадр за кадром, снизу вверх: выполняет все defer текущего кадра в порядке LIFO, снимает кадр, переходит к вызывающему. Если внутри отложенной функции вызван recover() (это runtime.gorecover), рантайм проверяет, что вызов сделан непосредственно из отложенной функции того кадра, который сейчас раскручивается, помечает _panic.recovered = true и через runtime.recovery восстанавливает SP/PC так, будто эта функция просто дошла до return. Именованные результаты функция вернёт такими, какими они остались на момент выхода из defer.

Если ни один defer не сделал recover, раскрутка доходит до вершины горутины, и рантайм вызывает runtime.fatalpanic. Та печатает panic: ..., трейсбек (по умолчанию только паникующей горутины; GOTRACEBACK=all печатает все, GOTRACEBACK=crash ещё и роняет процесс с core dump) и зовёт exit(2). Отложенные вызовы остальных горутин не выполняются - никакого «корректного завершения» при панике нет.

// Работает: recover прямо в отложенной функции
func ok() (err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("panic: %v", r)
        }
    }()
    panic("boom")
}

// Тоже работает: helper сама и есть отложенная функция
func ok2() {
    defer helper()
    panic("boom")
}

// Не работает: recover на уровень глубже
func bad() {
    defer func() {
        helper()      // recover внутри вернёт nil
    }()
    panic("boom")     // процесс всё равно упадёт
}

func helper() {
    if r := recover(); r != nil {
        fmt.Println("поймал:", r)
    }
}

// Запуск bad() на go1.27: «поймал: boom» не печатается, программа падает.
// stderr, exit status 2:
//   panic: boom
//
//   goroutine 1 [running]:
//   main.bad()
//           /tmp/x/main.go:11 +0x48
//   main.main()
//           /tmp/x/main.go:20 +0x1c
// recover() возвращает не-nil, только если вызван напрямую из отложенной функции
// паникующего кадра. Здесь helper - обычный вызов внутри defer, кадром глубже.

Panic и fatal error - это не одно и то же

Половина «неперехватываемых паник», которые приносят на собес, вовсе не паники. fatal error печатает рантайм напрямую, минуя механизм _panic: никакой раскрутки нет, defer не выполняются, recover физически не может сработать, потому что его никто не позовёт. Команда Go сделала так сознательно: после гонки по map её внутренности уже могли быть испорчены, и продолжать работу опаснее, чем упасть, а при дедлоке продолжать просто некому - спят все горутины.

Когда panic допустим

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

// Хорошо: константа, компилируется один раз при старте пакета.
var emailRe = regexp.MustCompile(`^[^@\s]+@[^@\s]+\.[a-z]{2,}$`)

// Плохо: паттерн из конфига. Одна опечатка в regex в YAML - и сервис не стартует
// или падает на первом же запросе.
func NewFilter(cfg Config) *Filter {
    return &Filter{re: regexp.MustCompile(cfg.Pattern)}   // NO
}

// Хорошо: ошибка конфига - это обычная ошибка.
func NewFilter(cfg Config) (*Filter, error) {
    re, err := regexp.Compile(cfg.Pattern)
    if err != nil {
        return nil, fmt.Errorf("bad filter pattern %q: %w", cfg.Pattern, err)
    }
    return &Filter{re: re}, nil
}

Почему panic не должен пересекать границу пакета

Как только твоя библиотека паникует на данных вызывающего, ты отнял у него право выбрать политику. Он хотел вернуть 400, залогировать и жить дальше - а получил падение процесса. Отсюда правило: panic остаётся внутри пакета, а наружу из экспортированной функции выходит только error.

Внутри пакета паника при этом бывает очень удобна: ею быстро выходят из глубокой рекурсии, где протаскивать error через двадцать уровней противно. Так делает сама стандартная библиотека: encoding/json, text/template, go/parser (там это буквально называется bailout) кидают панику собственного приватного типа и ловят её на границе экспортированной функции.

// Приватный тип - маркер «это наша паника, а не чужая».
type bailout struct {
    err error
}

func (p *parser) fail(format string, a ...any) {
    panic(bailout{fmt.Errorf(format, a...)})
}

// Экспортированная функция: наружу - только error.
func Parse(src []byte) (ast *AST, err error) {   // именованный результат обязателен
    defer func() {
        rec := recover()
        if rec == nil {
            return
        }
        b, ok := rec.(bailout)
        if !ok {
            panic(rec)      // чужая паника - пробрасываем как есть, не глотаем
        }
        err = fmt.Errorf("parse: %w", b.err)
    }()

    p := &parser{src: src}
    return p.parseFile(), nil
}

recover-middleware в HTTP-сервере

Свой recover у net/http уже есть. В conn.serve стоит defer, который ловит панику из хендлера, печатает http: panic serving 10.0.0.5:52341: ... со стеком в Server.ErrorLog и закрывает соединение. Процесс не падает - и на этом хорошие новости заканчиваются.

• Клиент не получает ответа. Соединение обрывается: на той стороне EOF, connection reset by peer или пустой ответ. Балансировщик посчитает это 502, а может и вообще не посчитает.
• В твоих метриках ничего нет. Хендлер не вернулся, значит, middleware метрик тоже не досчитало: http_requests_total{code="500"} не вырос, алерт не сработал.
• В логе нет контекста. За Server.ErrorLog стоит обычный log.Logger, который пишет в stderr без trace_id, без пользователя, без пути, без структурированных полей. Найти этот стек в Loki по trace_id ты не сможешь.
• Keep-alive убит. Соединение закрывается, клиент открывает новое, и на всплеске паник это заметная лишняя нагрузка.

// wrapWriter нужен, чтобы знать, начали ли уже писать тело:
// после первого Write статус ответа изменить уже нельзя.
type wrapWriter struct {
    http.ResponseWriter
    status int
    wrote  bool
}

func (w *wrapWriter) WriteHeader(code int) {
    if w.wrote {
        return
    }
    w.status, w.wrote = code, true
    w.ResponseWriter.WriteHeader(code)
}

func (w *wrapWriter) Write(b []byte) (int, error) {
    if !w.wrote {
        w.WriteHeader(http.StatusOK)
    }
    return w.ResponseWriter.Write(b)
}

func Recoverer(log *slog.Logger) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            ww := &wrapWriter{ResponseWriter: w}

            defer func() {
                rec := recover()
                if rec == nil {
                    return
                }
                // http.ErrAbortHandler - служебная паника самого net/http:
                // так хендлер сообщает серверу «оборви ответ молча».
                // Её нельзя глотать, иначе сломаем контракт сервера.
                if rec == http.ErrAbortHandler {
                    panic(rec)
                }

                log.ErrorContext(r.Context(), "panic in http handler",
                    slog.Any("panic", rec),
                    slog.String("method", r.Method),
                    slog.String("path", r.URL.Path),
                    slog.String("trace_id", traceID(r.Context())),
                    slog.String("stack", string(debug.Stack())),   // стек снимаем здесь,
                )                                                  // выше по стеку он уже потерян
                panicsTotal.WithLabelValues(r.Method, routePattern(r)).Inc()

                // Если тело уже пошло клиенту, статус не переписать -
                // остаётся только оборвать ответ, чтобы клиент увидел битый payload,
                // а не «успешный» усечённый JSON.
                if ww.wrote {
                    panic(http.ErrAbortHandler)
                }
                ww.Header().Set("Content-Type", "application/json; charset=utf-8")
                ww.WriteHeader(http.StatusInternalServerError)
                _, _ = ww.Write([]byte(`{"error":"internal","trace_id":"` + traceID(r.Context()) + `"}`))
            }()

            next.ServeHTTP(ww, r)
        })
    }
}

gRPC: здесь recover обязателен, а не желателен

У grpc-go нет встроенного recover. Паника в хендлере поднимается по горутине, обслуживающей стрим, доходит до вершины и роняет весь процесс - вместе со всеми остальными активными RPC. Один кривой запрос кладёт инстанс целиком. Поэтому recovery-интерцептор в бутстрапе обязателен, без вариантов.

func RecoveryUnary(log *slog.Logger) grpc.UnaryServerInterceptor {
    return func(ctx context.Context, req any, info *grpc.UnaryServerInfo,
        handler grpc.UnaryHandler) (resp any, err error) {

        defer func() {
            rec := recover()
            if rec == nil {
                return
            }
            log.ErrorContext(ctx, "panic in grpc handler",
                slog.String("method", info.FullMethod),
                slog.Any("panic", rec),
                slog.String("stack", string(debug.Stack())))
            panicsTotal.WithLabelValues("grpc", info.FullMethod).Inc()

            resp = nil
            // Наружу - только codes.Internal без деталей: текст паники
            // может содержать данные другого пользователя.
            err = status.Error(codes.Internal, "internal error")
        }()

        return handler(ctx, req)
    }
}

// Для стримов нужен отдельный интерцептор - StreamServerInterceptor,
// unary его не покрывает.

Паника из сторонней библиотеки

Шаги идут по убыванию правильности, а не удобства.

1. Локализовать и завести issue. Паника в чужом коде почти всегда означает баг библиотеки либо неверное использование её API. Воспроизведи минимальным тестом.
2. Запинить или форкнуть версию. Если баг известен и уже починен, обновись; если нет, сделай форк с патчем и replace в go.mod. Это честнее, чем прятать.
3. Обернуть вызов в собственный recover временно, с метрикой и алертом, чтобы «мы затыкаем чужую панику N раз в сутки» было видно.
4. Изолировать процессом, если библиотека совсем нестабильна (cgo-обёртки, парсеры чужих форматов, ffmpeg-биндинги): вынести её в отдельный бинарь и общаться через unix-сокет. Только так можно пережить и fatal error, и SIGSEGV из cgo.

// Обёртка-изолятор для одного вызова.
// Возвращает ошибку вместо паники и не глотает признак того, что паника была.
var ErrLibPanic = errors.New("third-party library panicked")

func safeDecode(b []byte, v any) (err error) {
    defer func() {
        rec := recover()
        if rec == nil {
            return
        }
        libPanics.WithLabelValues("badcodec.Decode").Inc()

        // Сохраняем и текст, и стек: без стека такую панику не найти,
        // потому что она пришла из чужого кода.
        err = fmt.Errorf("%w: badcodec.Decode: %v\n%s", ErrLibPanic, rec, debug.Stack())
    }()

    return badcodec.Decode(b, v)   // паникует на некоторых битых входах
}

Паника в чужой горутине: почему recover бессилен

recover() читает gp._panic текущей горутины. У новой горутины свой g, своя цепочка _defer и свой список паник. Кадры родителя в ней не участвуют, да и «родителя» у горутины формально нет: go f() не создаёт никакой связи, кроме записи в трейсбеке created by ....

// Единственная точка запуска горутин в проекте.
// Правило на ревью: голый `go` разрешён только внутри этого файла.
func Go(ctx context.Context, log *slog.Logger, name string, fn func(context.Context)) {
    go func() {
        defer func() {
            rec := recover()
            if rec == nil {
                return
            }
            log.ErrorContext(ctx, "panic in goroutine",
                slog.String("goroutine", name),
                slog.Any("panic", rec),
                slog.String("stack", string(debug.Stack())))
            goroutinePanics.WithLabelValues(name).Inc()
        }()
        fn(ctx)
    }()
}

// errgroup.Group.Go панику не перехватывает. Она только считает
// горутины и запоминает первую ошибку - паника внутри f() уходит наверх
// по своей горутине и роняет процесс. Хочешь пережить - ставь recover сам.

Паника в воркере пула

Даже те, кто помнит про safeGo, валятся на вопросе, где именно поставить recover. Если он стоит в самой функции воркера, воркер после первой же паники завершится, и пул тихо усохнет с 16 горутин до нуля, продолжая при этом «работать». Очередь будет расти, на метрику живых горутин никто не смотрит, инцидент найдут через сутки.

// Плохо: recover на уровне воркера.
// Одна паника - минус один воркер навсегда.
func (p *Pool) worker(id int) {
    defer func() {
        if r := recover(); r != nil {
            p.log.Error("worker died", "id", id)
        }
    }()
    for job := range p.jobs {
        job.Run()
    }
}

// Хорошо: recover на уровне одной задачи.
// Воркер переживает любую задачу.
func (p *Pool) worker(ctx context.Context, id int) {
    for job := range p.jobs {
        p.runOne(ctx, id, job)
    }
}

func (p *Pool) runOne(ctx context.Context, id int, job Job) {
    defer func() { ... recover, лог, job.Fail(...) ... }()
    job.Run(ctx)
}

func (p *Pool) runOne(ctx context.Context, workerID int, job Job) {
    defer func() {
        rec := recover()
        if rec == nil {
            return
        }
        p.log.ErrorContext(ctx, "panic while processing job",
            slog.String("job_id", job.ID),
            slog.Int("worker", workerID),
            slog.Any("panic", rec),
            slog.String("stack", string(debug.Stack())))
        jobPanics.WithLabelValues(job.Type).Inc()

        // Что делать с задачей, решай явно:
        //  - брокер: Nack без requeue -> DLQ (паника детерминирована, requeue = вечный цикл);
        //  - своя очередь: пометить failed с причиной, не возвращать в работу;
        //  - при at-least-once обязательно ограничить delivery_count.
        job.Fail(ctx, fmt.Errorf("panic: %v", rec))
    }()

    job.Run(ctx)
}

Panic и исключения других языков

Формально panic/recover устроены как исключения: та же раскрутка стека с перехватом. Отличаются они культурой применения и парой важных ограничений.

Стандартные паники Go: как звучат сообщения

Формулировки полезно помнить дословно: на собесе часто дают текст паники из прода и просят по нему назвать причину. Все эти паники перехватываются (в отличие от fatal error из таблицы выше).

Что выведет код?

func f() (n int) {
    defer func() {
        if r := recover(); r != nil {
            n = -1
        }
    }()
    defer fmt.Println("A")

    n = 1
    panic("boom")
}

func main() {
    fmt.Println(f())
    fmt.Println("done")
}

// вывод (проверено запуском на go1.27):
// A
// -1
// done
//
// Без имени у результата (func f() int) то же самое, но вместо -1 будет 0.

type bailout struct {
    err error
}

func Parse(src []byte) (ast *AST, err error) {   // именованный результат обязателен
    defer func() {
        rec := recover()
        if rec == nil {
            return
        }
        b, ok := rec.(bailout)
        if !ok {
            panic(rec)     // чужая паника - пробрасываем, не глотаем
        }
        err = fmt.Errorf("parse: %w", b.err)
    }()
    p := &parser{src: src}
    return p.parseFile(), nil
}

var ErrLibPanic = errors.New("third-party library panicked")

func safeDecode(b []byte, v any) (err error) {
    defer func() {
        rec := recover()
        if rec == nil {
            return
        }
        libPanics.WithLabelValues("badcodec.Decode").Inc()
        // Стек обязателен: без него чужую панику не найти.
        err = fmt.Errorf("%w: badcodec.Decode: %v\n%s", ErrLibPanic, rec, debug.Stack())
    }()
    return badcodec.Decode(b, v)
}

// Единственная точка запуска горутин. На ревью правило:
// голый `go` разрешён только внутри этого файла.
func Go(ctx context.Context, log *slog.Logger, name string, fn func(context.Context)) {
    go func() {
        defer func() {
            rec := recover()
            if rec == nil {
                return
            }
            log.ErrorContext(ctx, "panic in goroutine",
                slog.String("goroutine", name),
                slog.Any("panic", rec),
                slog.String("stack", string(debug.Stack())))
            goroutinePanics.WithLabelValues(name).Inc()
        }()
        fn(ctx)
    }()
}

func (p *Pool) worker(ctx context.Context, id int) {
    for job := range p.jobs {
        p.runOne(ctx, id, job)     // воркер переживает любую задачу
    }
}

func (p *Pool) runOne(ctx context.Context, workerID int, job Job) {
    defer func() {
        rec := recover()
        if rec == nil {
            return
        }
        p.log.ErrorContext(ctx, "panic while processing job",
            slog.String("job_id", job.ID), slog.Int("worker", workerID),
            slog.Any("panic", rec), slog.String("stack", string(debug.Stack())))
        jobPanics.WithLabelValues(job.Type).Inc()

        // Судьбу задачи выбираем явно: Nack без requeue -> DLQ.
        // Возвращать в очередь нельзя: паника детерминирована, будет вечный цикл.
        job.Fail(ctx, fmt.Errorf("panic: %v", rec))
    }()
    job.Run(ctx)
}

Что стоит запомнить

• Panic раскручивает стек текущей goroutine.
• recover срабатывает только внутри deferred функции той же goroutine.
• Ожидаемый сбой входа выражается через error.

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

• Main не перехватит panic worker goroutine.
• Middleware не делает допустимым panic на каждом ожидаемом пути.

func work() {
  defer func() { fmt.Println("recovered", recover() != nil) }()
  panic("broken invariant")
}
func main() { work() }

func main() {
  done := make(chan struct{})
  defer func() { fmt.Println(recover()) }()
  go func() { panic("worker failed") }()
  <-done // канал намеренно никто не закрывает
}