Go использует относительно иной подход к ошибкам по сравнению с такими языками, как Java, C++, JavaScript и Python: ошибка в Go — это значение встроенного типа error, которое функция обычно возвращает вызывающему коду вместе с другими возвращаемыми значениями. Благодаря этому проверка и обработка ошибки становятся явной частью потока программы, а не передаются отдельному механизму исключений.
В руководстве JetBrains, первоначально написанном участником сообщества Кристофом Бергером, а затем опубликованном в блоге JetBrains Go, представлен набор методов и практик для обработки ошибок ввода-вывода, сетевых ошибок, ошибок проверки данных и других проблем. Руководство было обновлено в августе 2026 года, чтобы соответствовать последним изменениям языка Go.
Возврат — отправная точка
Если у функции недостаточно контекста для обработки проблемы, она должна вернуть ошибку вызывающей функции. Обычно Go помещает значение ошибки в конец списка возвращаемых значений; например, функция ReadFile() возвращает содержимое файла и ошибку, значение которой равно nil при успехе и отличается от него при сбое.
В руководстве поясняется, что вызывающий код должен немедленно проверять ошибку, а не игнорировать её. Если функция открыла ресурс, например файл или сетевое соединение, следует использовать defer для его очистки при выходе, но только после подтверждения успешного открытия, поскольку попытка закрыть недействительный ресурс может привести к дополнительной проблеме.
Добавление контекста без повреждения структуры ошибки
Ошибка может пройти через цепочку функций, прежде чем будет обработана или записана в журнал. Во время этого перехода каждая функция может добавлять полезную информацию, например сведения о неудачной операции или обрабатываемом пути. Однако преобразование ошибки в текст с помощью объединения err.Error() приводит к потере цепочки и типовой структуры ошибки.
Правильный подход — использовать fmt.Errorf() с параметром %w, чтобы обернуть ошибку, сохранив исходную ошибку. Впоследствии это позволяет использовать errors.Unwrap() для доступа к одному уровню, а также errors.Is() и errors.As() для проверки конкретных ошибок внутри цепочки обёрток. В Go 1.26 появилась универсальная функция errors.AsType() — типобезопасная альтернатива As(); она возвращает соответствующую ошибку и логическое значение, позволяя компилятору обнаруживать ошибки типов, которые при старом подходе могли бы проявиться во время выполнения.
Несколько ошибок и отменённый контекст
Ошибки не всегда образуют линейную цепочку. Например, при обработке группы файлов одни операции могут завершиться успешно, а другие — с ошибкой. Стандартный пакет предоставляет errors.Join(), доступную начиная с Go 1.20, для объединения нескольких ошибок в одно значение с сохранением успешно обработанного содержимого.
В руководстве отмечается, что errors.Unwrap() возвращает одно значение и поэтому возвращает nil при работе с объединённой ошибкой. Для доступа к объединённым ошибкам необходимо проверить, реализует ли значение интерфейс, предоставляющий Unwrap() []error. Начиная с Go 1.20 также можно использовать context.WithCancelCause(), чтобы связать отмену контекста с пользовательской причиной, а затем получить эту причину через context.Cause(ctx), вместо того чтобы ограничиваться общим значением context.Canceled.
Когда уместен panic?
panic и recover не должны служить обычной заменой проверке ошибок. Ожидаемые ошибки, такие как некорректные пользовательские данные, отсутствующие файлы или сетевые тайм-ауты, следует обрабатывать и возвращать обычным путём возврата.
Паника уместна, когда проблема неожиданна и для неё не существует осмысленной обработки, например при сбое компиляции постоянного регулярного выражения, корректность которого следовало проверить заранее. В HTTP-серверах приложение может использовать recover() внутри отложенной функции, чтобы не допустить, чтобы сбой обработки текущего запроса повлиял на другие запросы, если это возможно. Однако такие ситуации, как исчерпание памяти, могут не оставить приложению практического способа продолжить работу.
Что практически важно для разработчиков?
- Не игнорируйте ошибки: присваивание значения ошибки пустому идентификатору или отбрасывание единственного возвращаемого значения может отсрочить обнаружение проблемы и усложнить диагностику её последствий.
- Записывайте ошибки в подходящем месте: функция должна обработать ошибку или вернуть её вызывающему коду. В руководстве рекомендуется, чтобы библиотеки не выполняли запись в журнал самостоятельно, поскольку их пользователи могут предпочитать другие журналы или направления вывода.
- Используйте подходящие типы: пользовательские типы ошибок могут содержать дополнительную информацию, как это делает fs.PathError, предоставляющий сведения об операции, пути и внутренней ошибке.
- Различайте сетевые ошибки: net.OpError позволяет проверить характер сбоя соединения, а временная ошибка может допускать повторную попытку или использование такой стратегии, как экспоненциальная задержка.
- Используйте количество байтов в операциях ввода-вывода: интерфейс io.Reader возвращает количество обработанных байтов вместе с ошибкой, что может помочь возобновить операцию, а не повторять передачу всех данных.
- Учитывайте io.EOF: это значение указывает на успешное завершение потока чтения согласно семантике пакета и не обязательно означает сбой, который следует записывать в журнал как обычную ошибку.
- Не используйте log.Fatal() без необходимости: она вызывает os.Exit(), что приводит к пропуску отложенных функций, поэтому руководство предлагает ограничить её использование или применять os.Exit() в функции main().
Редакционный вывод certi.news заключается в том, что ясность пути прохождения ошибки — часть проектирования программы, а не просто многословный стиль написания кода. Организованное обёртывание, подходящие типы и ответственное журналирование делают диагностику практически применимой, тогда как reliance на panic, общие сообщения или отбрасывание ошибок приводит к сокрытию информации, которая позднее потребуется разработчику. Практический выбор по-прежнему зависит от контекста приложения: серверу, обрабатывающему запросы, может потребоваться ограниченное восстановление, тогда как ошибка, после которой невозможно восстановиться, может потребовать завершения работы и перезапуска.