Функция recover() в Go останавливает панику только в том случае, если она вызывается непосредственно внутри отложенной функции, выполняющейся в процессе разворачивания, вызванного этой паникой. Когда вы вызываете recover() внутри вспомогательной функции, которая была вызвана отложенным замыканием, среда выполнения обнаруживает, что текущий кадр выполнения горутины не является верхним отложенным кадром, связанным с активной паникой.
// Этот шаблон НЕ УДАСТСЯ для восстановления: func handlePanic() { if r := recover(); r != nil { log.Println("Восстановлено:", r) } } func risky() { defer handlePanic() // recover() возвращает nil здесь panic("ошибка") }
Система runtime поддерживает эту проверку через поле g.recover, которое хранит указатель на стек кадра отложенной функции, обладающей правами на восстановление. Когда выполняется recover(), она сравнивает текущий указатель стека с этим хранимым значением; если они не совпадают, recover() возвращает nil, и паника продолжает подниматься по стеку. Это архитектурное ограничение гарантирует, что логика восстановления остается явной и локализованной, предотвращая случайное подавление паник глубоко вложенными вспомогательными функциями, которые должны распространяться на обработчики восстановления более высокого уровня.
В высокопроизводительном микросервисе, обрабатывающем тысячи одновременных горутин, мы реализовали централизованную механику восстановления от паники, чтобы предотвратить аварии сервера из-за неправильно сформированных запросов. Первоначальная реализация использовала утилитарную функцию SafeRecover(), которая инкапсулировала ведение журналов и метрики, и разработчики откладывали эту функцию в начале каждого обработчика, используя defer SafeRecover(). Однако, во время производственного инцидента, связанного с ошибкой деления на ноль в обработчике запросов, сервис упал, несмотря на кажущуюся механику восстановления, что указывало на то, что паника не была перехвачена, потому что recover() была вложена в вспомогательную функцию, а не вызвана напрямую.
Сначала мы рассмотрели возможность заставить разработчиков вручную писать defer func() { if r := recover(); r != nil { ... } }() в каждой точке входа функции. Этот подход обеспечивал прямой доступ к recover(), гарантируя соответствие времени выполнения, но ввел значительное дублирование кода и зависел от человеческой последовательности, что делало его подверженным ошибкам для большой команды и трудным в реализации во время ревью кода.
Второй подход заключался в том, чтобы изменить SafeRecover(), чтобы она принимала замыкание в качестве аргумента и выполняла recover() внутри переданной функции перед вызовом вспомогательной логики. Хотя это технически удовлетворяло требованию, помещая recover() в отложенный кадр, это создавало неуклюжий API, где обработчики должны были передавать свою логику восстановления в виде колбеков, что усложняло управление потоком и снижало читаемость, добавляя ненужную индирекции.
В конечном итоге мы выбрали третий подход: реализацию обертки промежуточного ПО на уровне HTTP маршрутизатора, которая выполняла defer func() { if r := recover(); r != nil { logAndMetrics(r) } }() непосредственно в отложенном замыкании промежуточного ПО. Это решение обеспечило вызов recover() на правильной глубине стека, сохраняя четкое разделение задач, что привело к 100% уровню перехвата паники во время последующего тестирования на хаос и нулевым циклам аварий в течение следующего квартала.
Почему recover() возвращает nil, когда вызывается вне отложенной функции, даже когда никакой паники не активно?
Вне контекста отложенного выполнения recover() запрашивает статус паники текущей горутины и не находит активной записи паники, что приводит к немедленному возврату nil. Тонкость заключается в том, что recover() проверяет, выполняется ли текущая функция в процессе разворачивания стека defer, а не только существует ли паника где-то в программе. Когда вызывается из обычных путей выполнения, среда выполнения находит поле _panic в структуре горутины равным nil и возвращает nil без побочных эффектов, предотвращая случайное злоупотребление тем, что нормальная обработка ошибок может инициировать механизмы восстановления.
Что происходит, когда несколько отложенных функций в одной горутине вызывают recover(), и почему удается только первой?
Когда происходит паника, Go выполняет отложенные функции в порядке LIFO, и первая отложенная функция, которая вызывает recover(), атомарно очищает состояние активной паники из внутреннего связного списка _panic горутины. Последующие отложенные функции, которые вызывают recover(), находят, что паника уже была разрешена, и получают nil вместо исходного значения паники. Этот дизайн обеспечивает детерминированную обработку паники, где внутренний контекст восстановления имеет приоритет и предотвращает избыточные попытки восстановления, которые могут запутать логику распространения ошибок, как только стек возвращается к нормальному выполнению.
Как behave panic(nil) отличается от panic("nil") или panic(0), и почему Go 1.21 изменила это поведение?
До Go 1.21, вызов panic(nil) заставлял среду выполнения рассматривать значение паники как специальный контрольный знак, что recover() вернет как nil, что делало его неразличимым от вызова recover(), который не нашел паники для обработки и создало опасную неоднозначность. В Go 1.21 и позже среда выполнения автоматически преобразует значение паники nil в ненулевую ошибку времени выполнения с сообщением "runtime error: panic called with nil argument", что гарантирует, что recover() всегда возвращает ненулевое значение, когда оно успешно перехватывает панику. Это изменение устранило неоднозначность в коде обработки ошибок, позволяя разработчикам уверенно проверять if r := recover(); r != nil, зная, что возвращенный nil действительно указывает на отсутствие паники.