Обработка ошибок в Go

Почему значения, а не исключения

Исключение - невидимый путь исполнения. Смотришь на строчку вызова и не знаешь, вылетит ли отсюда управление куда-то на пять уровней вверх. В Go этот путь сделан видимым: ошибка возвращается наравне с результатом, и её нельзя случайно не заметить.

Сам интерфейс минимален: один метод Error() string, и всё. Любой тип с этим методом - ошибка. Никакой иерархии классов исключений, никаких catch по типу - вместо этого обычные значения, которые можно сравнивать, оборачивать и передавать.

Цена честная: многословность. Три строчки после каждого вызова - реальность Go-кода, и с этим просто живут. Выигрыш - отсутствие невидимых выходов из функции и одинаковая форма обработки во всём коде: сначала ошибка, потом счастливый путь.

// Отсюда и стиль: сначала проверка ошибки с ранним возвратом, потом основная логика. Код читается сверху вниз без вложенности, а счастливый путь всегда прижат к левому краю.

Обработать один раз

Главное правило работы с ошибкой: у неё один обработчик. Либо ты с ней справился здесь, либо вернул выше - и тогда решает вызывающий. Оба действия сразу означают, что решения нет ни у кого.

Самое частое нарушение выглядит невинно: залогировал и вернул. В итоге одна проблема даёт три-четыре записи в журнале на разных уровнях, каждая со своим текстом, и разбирать инцидент приходится по обрывкам. Логирует тот, кто принимает решение, - обычно это обработчик запроса или главный цикл, самый верх.

Второе нарушение - проглотить ошибку через подчёркивание. Иногда это осознанно (закрытие файла, открытого только на чтение), и тогда рядом ставят комментарий. Чаще это просто «потом разберусь», которое живёт годами.

// Возвращая ошибку наверх, добавляй контекст: что именно делал. Не «not found», а «загрузка профиля пользователя 42: not found». Тогда по одной строчке лога понятно, где искать, без пляски со стеком.

// плохо: два обработчика на одну ошибку
if err != nil {
    log.Printf("не удалось прочитать: %v", err)
    return err   // выше залогируют ещё раз
}

// хорошо: добавили контекст и отдали решение выше
if err != nil {
    return fmt.Errorf("чтение профиля %d: %w", id, err)
}

Контракт возврата

Договорённость, на которую опирается весь Go-код: если ошибка не nil, остальные возвращаемые значения считаются негодными. Не «пустыми», не «частично заполненными» - негодными. Вызывающий обязан выйти, а не пытаться что-то из них извлечь.

Обратное тоже верно: если ошибка nil, результат обязан быть валидным. Функция, возвращающая иногда nil-ошибку с nil-результатом, ломает контракт, и её пользователи начнут писать двойные проверки на всякий случай.

Создают ошибки двумя способами. errors.New для простого текста - обычно на уровне пакета, в переменную. fmt.Errorf, когда нужна подстановка или обёртывание. Текст ошибки в Go пишут с маленькой буквы и без точки в конце: он почти всегда становится частью более длинной строки, и заглавная буква посреди фразы выглядит странно.

// Ошибка - часть публичного контракта пакета не меньше, чем сигнатуры. Если пользователи должны уметь отличать «не найдено» от «нет прав», это надо предусмотреть заранее: sentinel-значением или своим типом. Разбор текста ошибки строкой - признак того, что автор пакета об этом не подумал.

Как отвечать: «Что делать с ошибкой, полученной от вызова ниже?»

Одно из двух, и никогда оба сразу. Либо я обрабатываю её здесь - подставляю значение по умолчанию, повторяю попытку, возвращаю запасной ответ - и тогда наверх она уже не идёт. Либо возвращаю выше, обернув в контекст через fmt.Errorf с глаголом %w, чтобы сохранить оригинал для errors.Is и errors.As. Что я точно не делаю - не логирую и не возвращаю одновременно: это даёт три записи в журнале об одной проблеме и ни одного места, где принято решение. Логирует тот, кто решает, обычно самый верх - обработчик запроса. Контекст при обёртывании даю конкретный: что делал и с чем, например «чтение профиля 42». Тогда финальная строка лога сама рассказывает путь запроса. И держу в голове контракт: если ошибка не nil, остальные возвращённые значения негодны, доставать из них ничего нельзя.

Названо правило одного обработчика с объяснением, почему двойное действие вредно, показано оборачивание с сохранением цепочки и упомянут контракт возврата.

На чём валят

• −Логируют ошибку и возвращают её же - одна проблема даёт четыре записи в журнале.
• −Возвращают ошибку без контекста, и наверху остаётся голое «not found» без адреса.
• −Проглатывают ошибку через подчёркивание без комментария, почему это безопасно.
• −Используют значения, возвращённые вместе с ненулевой ошибкой.
• −Разбирают текст ошибки строкой вместо errors.Is или своего типа.
• −Пишут текст ошибки с заглавной буквы и точкой - он же попадёт в середину чужой строки.