Паника и восстановление

В Go две аварийные механики, и путать их дорого. Ошибка — значение типа error: функция вернула «не получилось», а вы решаете, что с этим делать. Мы разбирали эту идиому в уроке про ошибки. Паника — сломанная инвариантность: программа оказалась в состоянии, для которого у неё нет кода. Обращение по индексу за границей среза, разыменование nil, вызов метода по нулевому интерфейсу — runtime поднимает панику сам, а человек может сделать то же самое через panic(значение).

Что происходит при панике: выполнение текущей функции прекращается, начинают раскручиваться отложенные вызовы defer по всей цепочке вложенных функций, в stderr печатается трассировка, программа завершается с кодом возврата 2. Если на пути раскрутки ни одна отложенная функция не вызвала recover — спасти уже ничего нельзя: процесс умрёт целиком, вместе со всеми горутинами.

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

Это же делает панику «вежливее» мгновенных способов умереть: os.Exit обрывает процесс на месте, и отложенная уборка пропускается целиком.

Проверим на живом примере: функция risky паникует, но её отложенная уборка успевает напечататься. А вот код после вызова risky() в main — уже нет: панику никто не перехватил, и дальше раскрутка идёт до вершины.

Встроенная функция recover останавливает раскрутку и возвращает значение, переданное в panic. Работает она в единственном месте — внутри отложенной функции. Вызов recover() в обычном коде вернёт nil и ничего не изменит: механизм рассчитан именно на defer, потому что перехват должен случиться на пути раскрутки, а не где-то до или после неё.

Каноническая обёртка выглядит одинаково во всей экосистеме Go: defer func() { if r := recover(); r != nil { ... } }(). Внутри r — то, что передали в panic: строка, ошибка, любое значение. После успешного recover функция, в которой объявлен этот defer, возвращается нормально, и программа продолжает работу со следующего оператора после места, где объявлена обёртка.

Если паники не было, recover() возвращает nil — отсюда обязательная проверка r != nil: без неё обработчик сработает на каждом нормальном выходе из функции.

Что будет, если паниковать внутри обработчика recover? Раскрутка начнётся заново — уже с новым значением, — и перехватить её можно только на следующем уровне, где снова есть defer. Это основа паттерна «перехватил — не умею чинить — пробрось»: middleware логирует панику и метрики, а затем паникует дальше, если восстановить работу нельзя. В песочнице этот сценарий упрощён, поэтому runnable-примера не будет — проверяйте такое в настоящем Go.

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

Первая — recover вне defer. Выглядит правдоподобно: «а поставлю-ка я проверку в начале функции». Никакой ошибки компиляции не будет, recover просто вернёт nil, и паника однажды уронит программу мимо этой проверки. Диагностика неприятная: код выглядит защищённым, а защиты нет. Если пишете обёртку — начинайте её со строки defer func() {.

Вторая — recover без проверки на nil. Обработчик defer func() { recover() }() безусловно «срабатывает» на каждом выходе: без паники он бесполезен, а с побочными эффектами внутри — ещё и вреден, потому что выполняется каждый раз. Каноническая форма с if r := recover(); r != nil не украшение, а рабочий код.

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

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

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

Три границы механизма, о которых стоит знать заранее. Первая: os.Exit и log.Fatal умирают мгновенно — отложенные вызовы пропускаются, recover не срабатывает. Вторая: паника, поднявшаяся внутри обработчика recover во время раскрутки, начинается заново — аккуратно с побочными эффектами в самом обработчике. Третья: panic(nil) — особый случай; в новых версиях Go он превращается в искусственную ошибку runtime.PanicNilError, чтобы recover хотя бы мог отличить «настоящую» панику от пустой.

И про веб-серверы: стандартный http.Server сам ставит перехват вокруг обработчиков — упавшая паникой обработка рвёт одно соединение, а сервер продолжает слушать. Фреймворки вроде Gin добавляют собственные Recovery-middleware, чтобы логировать панику и отдавать аккуратный ответ 500. Самописные обёртки вроде protect из этого урока делают ровно то же самое — теперь вы умеете их писать с нуля.