panic(nil) и re-panic †

Panic(nil)

До Go 1.21 recover возвращал nil и когда паники нет, и при panic(nil) — отличить одно от другого было невозможно. С Go 1.21 panic(nil) передаёт в recover не nil, а *runtime.PanicNilError. Теперь проверка recover != nil честно означает «паника была».

Re-panic

Иногда поймать панику — не значит её обработать. Если defer понял, что эта паника не его, он обязан бросить её дальше:

defer func() {
    if r := recover(); r != nil {
        if _, ok := r.(myPanic); !ok {
            panic(r) // re-panic
        }
    }
}()

Re-panic продолжает разматывание, как будто recover не было.

Где recover действительно живёт

На границах, где паника не должна убить процесс. Классическое место — HTTP-сервер: стандартный net/http перехватывает панику на уровне соединения (в conn.serve), чтобы один упавший запрос не обрушил весь сервис. Или граница между чужим кодом и твоим, когда библиотека паникует, а тебе нужна ошибка.

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