Несколько возвращаемых значений и ошибки

Всё обучение вы уже сталкивались с ошибками в go, не называя их вслух: comma-ok из карт возвращал значение и флаг, divmod из функций — частное и остаток. Теперь наступает черёд самого важного применения нескольких return-значений — сообщения о проблемах. Ошибки в go — не исключения и не коды возврата: функция возвращает два значения — результат и ошибку. Ошибка — это обычный тип с именем error; значение nil означает «всё хорошо», любое другое — «что-то пошло не так, вот описание». Никакой магии: ошибка — такое же значение, как число или строка, её можно хранить в переменной, печатать, передавать дальше.

Идиома (value, err) закреплена во всём языке: почти каждая функция стандартной библиотеки, которая может не справиться, возвращает пару — результат первым, ошибку последней. Нашли запись в файле — значение и nil; не нашли — ноль и описание причины. Такое соглашение решает сразу две проблемы: вызывающий код не может «забыть» проверить ошибку, потому что она буквально выпадает из функции вместе с результатом, а сам поток программы остаётся видимым — никаких прыжков в неизвестную точку, как бывает с исключениями в других языках.

В этом уроке мы пройдём весь путь: создание ошибок через errors.New и fmt.Errorf, проверку if err != nil — самую частую строчку боевого Go-кода, собственную проверку деления на ноль, sentinel-ошибки по образцу ErrNoRows, обёртку причин через %w и ловушки приёма пары. Каждый ранимый пример прогнан на обоих движках песочницы — вывод совпадает, а места, где движки расходятся, честно оговорены и вынесены в неранимые блоки.

Запрос несколько return go обычно означает «как из функции вернуть сразу два значения» — ответ вы знаете: типы пишутся в скобках, return перечисляет значения через запятую. Но у пары (value, err) поверх механизма лежит контракт, и он важнее синтаксиса. Первое: порядок фиксирован — значение первым, ошибка последней. Не «ошибка и результат», не «что-то ещё и ошибка»: ошибка всегда завершает список, это читается в каждой сигнатуре языка одинаково.

Второе: при ошибке value — нулевое значение своего типа. divide при нулевом делителе вернула 0 — не мусор и не случайное число, а честный ноль, оговорённый return 0, err. Поэтому правило потребителя жёсткое: пока err != nil, результат не трогаем — там ноль, который ничего не значит. Печатать его можно, использовать в вычислениях — нельзя. Именно ради этого правила пары из ошибкой не смешивают с парами вроде (частное, остаток): остаток при частном имеет смысл, ноль при ошибке — нет.

Третье: nil — единственный знак успеха. Не нужно возвращать флаг «всё хорошо» отдельно или проверять результат на специальное «магическое» число. err == nil — всё хорошо, err != nil — проблема с текстом. Первый двухзначный возврат курса вы уже трогали, не называя: comma-ok из урока о картах — v, ok := m[k] — это чтение карты, возвращающее значение и флаг наличия, а divmod из урока о функциях — частное и остаток одной парой. Механизм один, семантика разная: comma-ok отвечает на вопрос «есть ли ключ», пара (value, err) — на вопрос «справилась ли функция».

Четвёртое: err из пары нельзя просто выбросить молча. Подчёркивание формально законно — res, _ := divide(5, 0) скомпилируется, — но это осознанное «я гарантирую, что ошибки не будет или она не важна». Ловушки такого игнора и неполного приёма одной переменной разберём отдельным разделом ниже, а пока запомните порядок чтения: сначала проверка err, потом работа с value.

Откуда берётся значение типа error? Из фабрик. Простейшая — errors.New: принимает строку и возвращает готовую ошибку с этим текстом. errors.New("деление на ноль") — вот и вся наука. Пакет errors подключается отдельно: import "errors" — рядом с fmt в блоке импорта.

Ошибку можно завести и без всяких функций: err := errors.New("что-то сломалось") — и это уже полноценное значение. fmt.Println(err) печатает текст; если err ещё не присвоили — var err error — печатается <nil>: нулевое значение типа error, знак «ошибки нет». Оба поведения пробником проверены — вывод одинаков в обоих движках.

У ошибки есть метод Error() string — он и превращает значение в текст. err.Error() возвращает ту же строку, что и печать: обычно fmt.Println(err) достаточен, Println вызывает Error() за вас. Метод пригодится, когда текст нужен именно как строка: склеить с префиксом, посчитать длину, передать в лог. Забавная деталь, которую вы уже знаете из урока о строках: len(err.Error()) считает байты, а не символы — для «oops» это 4, а для «нет данных» — 19, потому что кириллица занимает по два байта на букву.

Когда errors.New достаточен? Когда текст ошибки статичен: «деление на ноль», «список пуст», «не найдено». Как только в сообщение хочется подставить детали — какое число, какой индекс, какая строка — наступает очередь fmt.Errorf, о нём следующий раздел. Склеить строку оператором + можно и внутри errors.New — errors.New("не найдено: " + name) — законно и иногда удобно, но форматирование через Errorf читается чище.

fmt.Errorf — сестра fmt.Printf среди фабрик ошибок: принимает строку формата с глаголами и аргументы, возвращает ошибку с готовым, отформатированным текстом. fmt.Errorf("слишком большое число: %d", n) — в сообщении будет конкретное число. Глаголы те же, что в печати: %d для целых, %s для строк, %v для «как есть». Детали в тексте ошибки — не украшение: строка «ошибка» говорит только о факте беды, строка «слишком большое число: 200» сразу называет виновника, и отладка сокращается вдвое.

Возвращается пара как обычно: return 0, fmt.Errorf(...) — ноль и ошибка. А при удаче — return n * n, nil. Обратите внимание, как это выглядит в приёме: fmt.Println(v, err) печатает оба значения через пробел — «144 <nil>» при успехе и «0 слишком большое число: 200» при ошибке. Nil-ошибка в печати всегда выглядит как <nil> — и это норма, не сбой: Println честно показывает, что вторая часть пары пуста. В ранимом примере ниже ровно эта пара строк — пробник сверил её в обоих движках.

Слово Errorf расшифровывается как error + f (format) — по той же схеме, что Printf и Sprintf: f в конце имени функции fmt всегда означает строку формата. Ошибиться в регистре легко: fmt.errorf не существует, фабрика пишется с большой буквы — Errorf, как и все экспортируемые имена языка. Ошибка — обычное значение, и потому её тип в сигнатуре пишется без скобок, если пара одна: square(n int) (int, error) — значение int, ошибка error. Скобки вокруг списка возвратов нужны, когда значений больше одного; писать (int, error) — идиома, без них не обойтись.

Создать ошибку — полдела. Вторая половина — проверить её у вызывающего. Строчка if err != nil — самая узнаваемая конструкция Go: она встречается в боевом коде чаще любого другого оператора, и её пишут после каждого вызова, который умеет подводить. Схема неизменна: приём пары, проверка err, реакция. Реакция бывает трёх видов — напечатать и уйти (fmt.Println("ошибка:", err) и return), вернуть проблему выше (return 0, err — пробросить парой дальше), или справиться на месте (подставить значение по умолчанию, повторить попытку). В runner-е урока вы видели первый вид: печать и return — main честно сообщает причину и заканчивается.

Проверку удобно писать в форме оператора с объявлением: if err := divide(7, 0); err != nil { ... } — err объявляется прямо в заголовке if и живёт только внутри проверки. Экономится строка, а область видимости не мусорится — err не протекает в код ниже. Когда ошибка нужна и после проверки (например, в else-ветке или дальше по функции), приём делают заранее: res, err := divide(...) — и then обычный if err != nil без объявления.

Повторный вызов той же функции не требует второй :=: res, err = divide(...) — переменные уже есть, присваивание через =, ровно как с comma-ok и divmod. Одна переменная err переживает цепочку вызовов: после каждого присваивания она снова либо nil, либо свежая ошибка. Проверка на удачу — if err == nil — тоже законна, но идиоматичнее спрашивать о беде: err != nil. А ветка else берётся редко: если ошибки нет — просто работаем дальше без вложенного уровня. Правило читаемости: обработали err — сразу return; код счастливого пути держится левым краем, без лестницы вложенных else.

Самый короткий путь понять идиому — спроектировать проверку с нуля. Возьмите деление: язык целочисленного деления на ноль не прощает — в рантайме настоящей программы паника, а не ошибка. Значит, функция деления обязана проверять делитель сама и возвращать ошибку парой. Три решения на этапе проектирования. Первое: какие случаи неправильные — для деления он один, if b == 0. Второе: какой текст вернуть — конкретный и без лишних слов: «деление на ноль». Третье: что вернуть в value — по контракту ноль: return 0, errors.New("деление на ноль").

Такая проверка называется guard — часовой в начале функции: частный случай отработан — выход с ошибкой, общий случай — ниже, в return a / b, nil. Вы уже писали guard в уроке о функциях — там он возвращал безопасный ноль молча; разница ровно одна: теперь выход несёт объяснение, и вызывающий код узнаёт причину, а не угадывает её по нулю.

Дальше — расплата за честность: каждый вызывающий обязан решить, что делать с ошибкой. В main мы печатали и выходили. В цикле — продолжаем со следующей пары: v, err := safeDiv(...), if err != nil { печать; continue } — итерация пропущена, цикл живёт дальше. В другом коде — подставляем запасное значение или пробрасываем ошибку выше со своим контекстом. Одинаковый скелет, разная реакция — и в этом смысл: решение о судьбе ошибки принимает тот, у кого достаточно знаний о программе. Ранимый пример с циклом из трёх пар ждёт ниже — на нём видно, как ошибка не прерывает обработку списка, а лишь помечает одну строку.

Когда один и тот же текст ошибки нужен в нескольких местах или его хочется проверять программно, текст выносят в переменную уровня пакета: var ErrDivZero = errors.New("деление на ноль"). Такая переменная называется sentinel-ошибкой — сторожевой: она одна на весь пакет, объявлена заранее и возвращается функциями как есть — return 0, ErrDivZero. Имя по стилю языка: Err и продолжение с большой буквы — ErrDivZero, ErrEmpty, ErrNotFound.

Стандартная библиотека набита sentinel-ошибками — это стиль ErrNoRows: пакет database/sql объявляет sql.ErrNoRows — «строк по запросу не нашлось», пакет io — io.EOF — «данные кончились», пакет strconv — ErrSyntax — «не удалось разобрать строку». Заметили закономерность? Конкретное имя после Err, объявление в пакете, один смысл на всё API. Ваш код делает то же самое своими руками: ErrDivZero в runner-е ниже — мини-версия ErrNoRows, только про деление.

Зачем это нужно. Первое — переиспользование: текст написан один раз, все функции пакета возвращают одинаковую формулировку. Второе — документация: sentinel в сигнатуре пакета — обещание «эта ошибка возможна», читатель API видит список ожидаемых проблем. Третье — сравнение: теперь можно спросить, является ли вернувшаяся ошибка именно этой. Инструмент сравнения — errors.Is(err, ErrDivZero) — и вот тут начинаются песочничные тонкости: основной движок — настоящий Go — сравнение исполняет, резервный не знает члена Is в пакете errors, поэтому блок с ним ниже сделан неранимым с честной оговоркой. Печатать же sentinel и оборачивать его через %w умеют оба движка — этим и займёмся.

Глагол %w в fmt.Errorf — отдельная суперсила: он вставляет исходную ошибку внутрь новой, сохраняя её значение, а не только текст. fmt.Errorf("%d / %d: %w", a, b, ErrDivZero) собирает сообщение из деталей и причины: напечатается «8 / 0: деление на ноль» — что делили, на что, и почему нельзя. Разница с подстановкой %v или склейкой строк принципиальна: %w хранит связь «новая ошибка является причиной-ошибкой», и по этой связи потом можно пробраться к корню — именно так errors.Is находит sentinel сквозь любые слои обёртки.

Обёртки вкладываются друг в друга: err := fmt.Errorf("поиск: %w", ErrNotFound), затем err2 := fmt.Errorf("слой 2: %w", err) — печатается «слой 2: поиск: не найдено». Так выглядит честная трассировка без исключений: каждый уровень добавляет свой контекст — функция, аргумент, операция — и передаёт проблему выше, ничего не теряя. Низовой уровень знает «что сломалось», верхние — «в какой операции»: вместе они дают полный рассказ.

Эта тема — вход в большой мир обработки ошибок: сравнение через errors.Is, выделение конкретных типов через errors.As, собственные типы ошибок с полями-деталями. Продвинутый курс отводит ей целый урок о заворачивании ошибок — там будут и цепочки причин, и кастомные структуры-ошибки; здесь достаточно привычки: возвращая ошибку из глубины, оборачивайте её с контекстом — «не могу прочитать файл: %w» вместо голого переприсваивания. Печать %w-обёрток работает в обоих движках песочницы — ранимый runner выше это показал; вся магия сравнения остаётся за настоящим Go до неранимого блока.

У пары (value, err) две классические ловушки, и обе — на стороне приёма. Первая — неполный приём: q := divmod(17, 5) — одна переменная на два возврата. Настоящий компилятор Go это отвергает: assignment mismatch, два значения не умещаются в одно. А вот оба движка песочницы — и основной, и резервный — молча берут первое значение, и программа выглядит рабочей: основной yaegi здесь расходится с настоящим компилятором, резервный просто упрощает. Для пар с ошибкой эта мягкость особенно коварна: q := divide(7, 0) положит в q ноль, а ошибку выбросит — код напечатает ноль и промолчит о причине. Правило одно для всех сред: два возврата — две переменные или явное подчёркивание. Локальный компилятор поймает вашу опечатку, песочница — нет, так что привычка нужна независимо от среды.

Вторая ловушка — глухой игнор: res, _ := divide(5, 0). Подчёркивание формально законно — оба движка вернут ноль и три в примере ниже, — но ошибка выброшена без просмотра. Так писать стоит только с осознанной гарантией: «ошибка здесь невозможна или для программы безразлична». Таких мест в реальном коде — единицы, а вот байт-в-байт совпадающих с ними строк, где автор просто поленился, — тысячи. Рецепт: пока не уверены — не игнорьте; печать, проброс или обработка всегда лучше молчания. Quiz выше и predict ниже прогонят обе ловушки через вас лично.

И две мелочи напоследок. Сигнатуры с разными типами параметров — find(s []string, want string) — валидны в настоящем Go, но резервный не парсит их (квирк из урока о функциях), поэтому все ранимые примеры урока держатся групповой формы (a, b int) или одного параметра. А именованные возвраты с ошибкой — (q int, err error) — резервный движок не читает по той же причине, что и любые именованные результаты: форма настоящая, законная (пробник проверил на настоящем Go: 4 <nil> и 0 деление на ноль), но в песочнице только текстом, как договорились в уроке 20.

Во многих языках ошибка сигнализируется исключением: функция бросает, стек разматывается, ближайший обработчик ловит. В Go этот путь выбран сознательно против. Аргументы три. Первый — видимость потока: если ошибка — значение из пары, то каждая точка, где может случиться беда, видна в коде буквами if err != nil; с исключениями полный список возможных сбоев в функции выписать невозможно — бросить может любой вызов на любую глубину. Второй — цена управления: разматывание стека и ловля исключений дороже простого возврата значения, а Go строился для сервисов, где миллионы вызовов в секунду. Третий — принуждение: пара (value, err) физически не даёт проигнорировать ошибку случайно — значение выпадает наружу, и его нужно куда-то положить.

Плата известна — многословность: строка if err != nil повторяется десятки раз. Го-сообщество считает её честной ценой за читаемость: взамен код без скрытых путей исполнения, который можно читать сверху вниз и точно знать, где что может сорваться. Снизить шум помогает дисциплина из этого урока: обёртка с контекстом через %w, sentinel-ы для известных случаев, обработка в одном месте — в main или на границе сервиса.

Уточнение для честности картины: паника в Go существует — механизм аварийного выхода для неисправимых ситуаций вроде индекса за границей среза или деления на ноль в чистом коде; её разбор — panic и recover — живёт в продвинутом курсе, там же, где и defer. Но паника — не исключение и не канал обычной обработки: она для багов, а не для «файла не нашлось». Ошибки в go — это всегда пара значений и явная проверка: до указателей из урока 22 ещё два шага, а главный контракт взаимодействия функций между собой вы уже знаете.