Ошибки — это значения: обёртывание, сентинелы и дисциплина if err != nil

Ошибки — значения, и это осознанная позиция

Когда вы впервые пишете Go после языка с исключениями, блоки if err != nil кажутся шумом. Они не шум — они и есть суть. В Go error — просто интерфейс с одним методом Error() string, а ошибка — обычное значение, которое возвращают, проверяют, складывают в срез, сравнивают. Ритуал if err != nil, над которым смеются новички, и есть суть: каждый путь отказа виден в коде, который по нему идёт. Go отказался от исключений намеренно. С исключениями любая строка может передать управление обработчику за много страниц отсюда — чтение функции ничего не говорит о её путях выхода; со значениями-ошибками поток управления — ровно то, что написано. Цена — повторение: if err != nil { return ... } повсюду, и Go принимает эту цену сознательно: скучная, явная обработка отказов читается одинаково в любой кодовой базе, а эти три строки — место, где вы добавляете контекст, а не просто пробрасываете ошибку вверх.

func loadConfig(path string) (*Config, error) {
    raw, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("load config %q: %w", path, err)
    }
    cfg, err := parse(raw)
    if err != nil {
        return nil, fmt.Errorf("parse config %q: %w", path, err)
    }
    return cfg, nil
}

Каждый return аннотирует ошибку тем, что делал этот слой, и итоговое сообщение читается как причинная цепочка: load config "/etc/app.yaml": open /etc/app.yaml: permission denied. Стек-трейс не нужен — цепочка и есть трейс, на языке предметной области.

Обёртывание: %w строит цепочку, errors.Is и errors.As по ней ходят

fmt.Errorf с глаголом %w не просто форматирует — он сохраняет обёрнутую ошибку, давая новой ошибке метод Unwrap() error. Наслоите достаточно уровней — получите связный список ошибок. По нему ходят две функции. errors.Is(err, target) идёт по цепочке, спрашивая «является ли какое-то звено именно этим значением?» — безопасная к обёртыванию замена == и однотокенный фикс пятисоток из вступления. errors.As(err, &target) идёт по цепочке, спрашивая «есть ли звено этого типа?», и копирует совпадение наружу — так вы достаёте типизированные данные (код *pgconn.PgError, путь *os.PathError), не зная, сколько слоёв их обернуло.

_, err := repo.GetProfile(ctx, id)

if errors.Is(err, sql.ErrNoRows) {      // работает через любое число %w-обёрток
    return nil, ErrProfileNotFound
}
var pgErr *pgconn.PgError
if errors.As(err, &pgErr) && pgErr.Code == "23505" {
    return nil, ErrDuplicate            // типизированные данные, извлечённые из цепочки
}

Ловушка — %v против %w: %v сплющивает ошибку в текст и отбрасывает цепочку — errors.Is через него возвращает false. Используйте %w, когда вызывающим может понадобиться причина; используйте %v намеренно, когда хотите запечатать ошибку на границе, чтобы вызывающие не связались с внутренностями. Этот выбор — дизайн API: каждый %w делает обёрнутую ошибку частью вашего контракта — смените потом sql.ErrNoRows на другой драйвер, и проверки errors.Is у вызывающих молча перестанут совпадать.

Сентинел, типизированная, непрозрачная: три уровня связности

Есть три идиомы, упорядоченные по тому, сколько обязан знать вызывающий. Сентинел-ошибки — значения уровня пакета вроде io.EOF, sql.ErrNoRows или ваш var ErrNotFound = errors.New("not found") — дёшевы (сравнение указателей через errors.Is) и позволяют ветвиться по идентичности, но это вечный публичный API без данных. Типизированные ошибки — структуры, реализующие error, как *os.PathError, — несут поля (какой путь? какой код?) и матчатся через errors.As, ценой экспорта типа, вокруг которого вызывающие выстроят ожидания. Непрозрачные ошибки — просто вернуть error, ничего не выставляя — минимизируют связность: вызывающий может только залогировать или пробросить, а вы свободны менять всё за текстом сообщения. Сеньорский дефолт — сначала непрозрачно: экспортируйте сентинел или тип, только когда вызывающему доказуемо нужно ветвиться на этом отказе, потому что каждая экспортированная ошибка — контракт, который вы будете поддерживать вечно.

panic — для багов; настоящий убийца — проглоченная ошибка

panic раскручивает стек, выполняя отложенные функции, пока его не остановит recover — или процесс не завершится. Его работа — невосстановимая ошибка программиста: индекс за границей, запись в nil-map, «эта ветка невозможна». Это не канал потока управления для ожидаемых отказов — отсутствующая строка в базе не повод для panic. recover используйте только на границах горутин — в per-request middleware HTTP-сервера, в обёртке worker-пула — чтобы превратить «один багованный запрос» в 500 вместо мёртвого процесса. И деталь, убивающая сервисы: recover работает только внутри отложенной функции паникующей горутины. Паника в горутине, запущенной через go, игнорирует все recover родителя — и роняет весь процесс. Каждая go func(), выполняющая сторонний или зависящий от запроса код, обязана иметь свой отложенный recover.

Самый частый продакшен-отказ — вовсе не паника, а проглоченная ошибка:

data, _ := fetch(ctx, key)        // err отброшен: data — НУЛЕВОЕ ЗНАЧЕНИЕ
process(data)                     // nil-разыменование или пустой результат — далеко от причины

if err := step(); err != nil {
    log.Printf("step failed: %v", err)
    // ...and execution continues as if it succeeded
}

Отбросьте через _ — и нулевое значение потечёт вниз по потоку, взорвавшись nil-разыменованием или молча пустым ответом в коде, который выглядит невинно: место падения и причина окажутся в разных файлах. «Залогировать и продолжить» коварнее: функция работает дальше со сломанным состоянием, а строчка лога проматывается непрочитанной. Дисциплина: каждая err либо обработана (по ней ветвление, компенсация), либо возвращена с контекстом %w, либо — редко — отброшена через _ с комментарием, почему это безопасно. Третьего не дано.