Ошибки в Go: одна буква, которая рвёт цепочку, и утверждение типа, которое перестанет работать

Что здесь на самом деле спрашивают

Лестница почти всегда такая:

1. «Что такое error в Go?» — разминка: интерфейс с одним методом.
2. «Чем %w отличается от %v?» — здесь отваливается первая половина.
3. «Почему err == ErrNotFound перестало работать?» — про обёртку.
4. «Is или As?» — и почему утверждение типа хуже обоих.
5. «Что такое sentinel-ошибка и когда её не надо?» — про обязательства.
6. «Сколько это стоит?» — вопрос на честность.

Дальше урок идёт по этой лестнице. Спина у неё одна: обёртка — это ссылка вниз, и всё поведение зависит от того, есть ли она.

База: ошибка — это значение, которое передают выше

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

Выглядит он так, и других участников в нём нет:

1. функция обнаружила неудачу и вернула ошибку вызывающему;
2. вызывающий проверил её и решает: разобраться самому или передать выше;
3. если передавать — он добавляет контекст: где и зачем он это делал, — и возвращает результат дальше;
4. кто-то наверху принимает решение: ответить клиенту, повторить попытку, записать в лог. Решает один, и обычно это обработчик запроса, воркер или main.

Ключевой здесь третий шаг. Ошибка идёт снизу вверх и по дороге обрастает контекстом: open /etc/app.yaml: no such file превращается в load config: open /etc/app.yaml: no such file, а потом и в serve: load config: …. В логе это читается как один путь — от места решения до места отказа.

И вот главный вопрос урока: что происходит с исходной ошибкой, когда к ней добавляют контекст? Наверху ведь надо не просто напечатать текст, а понять, что случилось: «файла нет» — это одно решение, «нет доступа» — другое. Значит, добавление контекста обязано сохранить то, по чему наверху будут различать.

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

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

Механизм 1: три задачи, которые решает error

У работы с ошибками ровно три задачи, и почти вся путаница берётся из того, что их не разделяют:

Каждая следующая строка опирается на предыдущую: классифицировать можно только то, что не потеряно при добавлении контекста. Урок идёт по этим трём задачам.

Начнём с первой, и она короче всех:

type error interface {
    Error() string
}

Всё. Отсюда сразу три следствия, которые стоит назвать:

• Ошибка — обычное значение. Её можно положить в переменную, сравнить, передать, вернуть — и она ничем не отличается от других значений.
• Любой тип с методом Error() string — ошибка. Никакой регистрации не нужно.
• error — интерфейс, а значит, на него распространяется ловушка типизированного nil. Функция, объявленная возвращающей error, но возвращающая переменную конкретного типа, вернёт «ошибку» и тогда, когда её нет.

Про оформление есть соглашение, которое проверяют на ревью:

Отсюда и форма обёртки: fmt.Errorf("load config: %w", err) — глагол и двоеточие, а не законченное предложение. Читается это снизу вверх как один путь: serve: load config: open /etc/app.yaml: no such file.

Механизм 2: одна буква решает всё

Две строки, отличающиеся одним символом:

fmt.Errorf("ctx: %w", err)   // цепочка сохранена
fmt.Errorf("ctx: %v", err)   // цепочка разорвана

Сообщение в логе у них одинаковое. Разница только в том, держит ли новая ошибка ссылку на старую:

Переключайте случаи — видно, есть ли под верхней ошибкой ссылка вниз:

Проверено прогоном:

И сразу третья строка того же прогона: wrapped() == errNotFound даёт false. Сравнение == смотрит на само значение, а после обёртки это уже другое значение. Отсюда правило: sentinel-ошибки сравнивают через errors.Is, а не через == — иначе код ломается от чужой правки, добавившей обёртку двумя уровнями ниже.

Механизм 3: Is и As — это обход цепочки, а не магия

Прежде чем смотреть на сигнатуры, стоит сказать, что эти функции делают, — иначе они запоминаются как две волшебные проверки, которые «как-то умеют».

Обе делают одно: идут по цепочке Unwrap от внешней ошибки к внутренней и на каждом шаге задают свой вопрос.

errors.Is спрашивает «это то самое значение?», errors.As — «это тот самый тип?». Всё остальное — детали: обе останавливаются на первом «да», обе возвращают false, дойдя до конца цепочки.

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

Разница между Is и As простая, если запомнить, что каждый ищет.

errors.Is ищет конкретное ЗНАЧЕНИЕ — обычно sentinel вроде os.ErrNotExist:

errors.As ищет конкретный ТИП и заодно достаёт значение, чтобы можно было прочитать поля:

var pathErr *fs.PathError
if errors.As(err, &pathErr) {
    log.Println(pathErr.Path)   // ради этого As и нужен
}

А хуже обоих — утверждение типа. Оно смотрит только на верхний уровень:

Это одна и та же ошибка. Разница в том, что между ней и типом в основании оказались две обёртки. Опаснее всего здесь не сам факт, а то, как он проявляется: код с утверждением типа работает ровно до первой правки, которая добавит обёртку уровнем выше — и перестаёт работать молча, без ошибки сборки и без падения тестов.

Отсюда правило: в обработке ошибок утверждение типа не используют вовсе. Есть errors.As, и он делает то же самое, только по всей цепочке.

Механизм 4: Join — это дерево, а не обёртка

errors.Join появился в Go 1.20 и путается с обёрткой чаще всего.

err := errors.Join(errA, errB)
errors.Is(err, errA)   // true
errors.Is(err, errB)   // true
errors.Unwrap(err)     // nil ← вот здесь ошибаются

Причина в том, что Join реализует Unwrap() []error, а не Unwrap() error. Одноместный errors.Unwrap для него не определён и честно возвращает nil. Разворачивать такую ошибку надо через Is/As, которые умеют обходить дерево.

То же самое, кстати, делает fmt.Errorf с несколькими %w: в документации это сказано прямо — при нескольких глаголах возвращается Unwrap() []error.

Где Join уместен. Там, где ошибок действительно несколько и все они равноправны: проверка конфигурации, разбор формы, закрытие нескольких ресурсов. Там, где ошибка одна, а нужен контекст, — это %w, а не Join.

Механизм 5: оборачивать — значит брать обязательство

Самый неочевидный ответ этой темы, и его стоит уметь дать.

Читать это надо так: как только вы обернули sql.ErrNoRows через %w, вызывающий может написать errors.Is(err, sql.ErrNoRows) — и он это сделает. Смена базы данных или переход на другой драйвер сломает чужой код, хотя ваша сигнатура не менялась.

Практическое правило получается такое: внутри пакета оборачивайте %w свободно; на границе пакета решайте осознанно. Наружу обычно выпускают свои sentinel-ошибки (repo.ErrNotFound), а чужие переводят в них — так внутренняя кухня не становится обязательством.

Что выбрать: таблица решения

Четыре способа сообщить о причине, и выбирают между ними не по вкусу:

Последняя строка — единственный законный случай для %v, и она объясняет, почему обе формы оставлены в языке. %v означает «текст причины в логе нужен, а программная проверка — нет». Проблема не в самой форме, а в том, что её ставят случайно: в логе обе выглядят одинаково.

Глубже: сколько это стоит

Числа — из прогона bench/goerrors/internals.go, снятого один раз на одной машине: у вас наносекунды будут своими, а соотношения — те же по знаку.

Обёртка стоит заметно, но платится только на пути ошибки:

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

Вторая строка — отдельный практический вывод: errors.New внутри функции создаёт новую ошибку на каждый вызов. Sentinel объявляют один раз на уровне пакета, и не только ради этих тридцати наносекунд, а чтобы по ней можно было сравнивать.

А вот проверка платится всегда, и растёт с глубиной:

errors.Is снимает обёртки по одной, поэтому цена почти линейна по глубине. Отсюда практическое: оборачивать стоит там, где добавляется смысл, а не на каждом уровне подряд. Три обёртки вида a: b: c: реальная причина полезны; пятнадцать — это шум в логе и восемь лишних звеньев на каждой проверке.

Как отвечать на собеседовании

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

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

На «что такое error» отвечайте одной строкой определения. «Интерфейс с методом Error() string; отсюда и то, что на него распространяется ловушка типизированного nil».

Про %w и %v говорите про ссылку, а не про «оборачивает». «%w сохраняет ссылку на исходную ошибку, %v вставляет её текст; сообщение одинаковое, а errors.Is даёт true и false».

Про == назовите последствие. «После обёртки это другое значение, поэтому сравнивают через errors.Is — иначе код ломается от чужой правки двумя уровнями ниже».

Про Is и As скажите, что ищет каждый. «Is — значение, As — тип, и As заодно достаёт поля. А утверждение типа не используют вовсе: оно смотрит только на верхний уровень и молча перестаёт работать после первой же обёртки».

Про Join скажите «дерево». «Он реализует Unwrap() []error, поэтому одноместный Unwrap возвращает nil, а разворачивать надо через Is/As».

Про цену разделите два числа. «Обёртка — сотни наносекунд и два выделения, но только на пути ошибки. А проверка платится всегда и растёт с глубиной: на двадцати обёртках errors.Is дороже в восемь раз».

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

fmt.Println(errors.Is(wrapped(), errNotFound))
fmt.Println(errors.Is(formatted(), errNotFound))

fmt.Println(wrapped() == errNotFound)

var target *NotFoundError
fmt.Println(errors.As(typedWrapped(), &target))
_, ok := typedWrapped().(*NotFoundError)
fmt.Println(ok)

fmt.Println(errors.Unwrap(typedWrapped()))

true
false
false
true
false
inner: no key k

true
true
true
true
true
inner: no key k

true
false
true
true
false
no key k

true
false
false
true
true
outer: inner: no key k

Проверка знаний