Краткий ответ

panic оправдана, когда нарушен внутренний инвариант программы, то есть условие, которое корректный вызывающий код не должен нарушать. Ожидаемые сбои среды, некорректные входные данные и временные проблемы следует возвращать как error.

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

Исторический контекст

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

panic предназначена для прекращения нормального выполнения при невозможном или непредвиденном состоянии. Механизм recover позволяет перехватить панику на специально выбранной границе, но не превращает её в обычный способ передачи ожидаемых ошибок.

Постановка проблемы

Если функция паникует из-за неверного пользовательского ввода, недоступной базы данных или тайм-аута, вызывающий код теряет возможность нормально выбрать реакцию: повторить операцию, вернуть понятный ответ или использовать запасной вариант.

Если же функция возвращает error после нарушения внутреннего инварианта, дефект может быть замаскирован как обычный операционный сбой. Программа продолжит работу с некорректным состоянием, а причина ошибки станет труднее обнаружимой.

Подробное решение

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

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

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

Публичная библиотека должна быть особенно осторожна: паника из-за обычных аргументов делает API хрупким и вынуждает каждого пользователя устанавливать защитную границу. Если библиотека документирует панику только для нарушения программистского контракта, это должно быть явно указано.

package main

import (
	"errors"
	"fmt"
)

func ParsePort(s string) (int, error) {
	var port int
	if _, err := fmt.Sscanf(s, "%d", &port); err != nil {
		return 0, fmt.Errorf("invalid port: %w", err)
	}
	if port < 1 || port > 65535 {
		return 0, errors.New("port is out of range")
	}
	return port, nil
}

func RequirePositive(n int) {
	if n <= 0 {
		panic("internal invariant violated")
	}
}

Здесь неверная строка порта является обычной ошибкой внешних данных. Неположительное значение в RequirePositive трактуется как нарушение внутреннего контракта и приводит к панике; в реальном коде такой контракт должен быть обоснован окружающей логикой.

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

Ситуация из практики

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

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

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

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

Что кандидаты часто упускают

Вопрос: Может ли отсутствие подходящего обработчика panic оправдывать выбор panic вместо error?

Ответ: Нет. Наличие или отсутствие recover определяет последствия паники, но не классифицирует саму ситуацию. Если вызывающий код должен штатно принять решение, функция обязана вернуть error, даже если на верхнем уровне нет восстановления. Паника выбирается из-за нарушения внутреннего контракта, а не ради удобства завершения процесса.
Вопрос: Должна ли функция паниковать при аргументе, который формально не запрещён типом, но не поддерживается алгоритмом?

Ответ: Только если это явно закреплённый программистский контракт и его нарушение означает дефект вызывающего кода. Если значение может естественно появиться из пользовательского ввода, сети или файла, безопаснее вернуть error. Для публичного API контракт, ведущий к панике, нужно документировать; иначе пользователи не смогут надёжно отличить ошибку использования от внутреннего сбоя.
Вопрос: Почему превращение любой panic в error на верхнем уровне не делает архитектуру автоматически надёжнее?

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