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

Если метод Error имеет только указательную receiver-форму, ошибкой, то есть реализацией интерфейса error, будет считаться только указатель на этот тип. Значение структуры нельзя напрямую присвоить переменной типа error; обычно возвращают *ТипОшибки.

Это влияет на API функции, копирование значений и использование errors.As. При этом интерфейс error может содержать nil-указатель, поэтому результат такой функции всё равно способен быть неравен nil.

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

В Go интерфейсы реализуются неявно: тип удовлетворяет интерфейсу, если его методовый набор содержит необходимые методы. Интерфейс error требует метод Error() string, поэтому выбор между value receiver и pointer receiver определяет, какие формы типа могут быть ошибками.

Различие связано с общей моделью методов Go: значение и указатель на значение имеют разные методовые наборы. Это позволяет явно выбрать между копированием ошибки как значения и передачей одного объекта по указателю.

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

Рассмотрим структуру ошибки с Error только у указателя. Разработчик может попытаться вернуть её значение из функции, объявленной как возвращающая error, и получить ошибку компиляции.

Обратная сторона также важна: если функция возвращает nil-указатель конкретного типа как error, интерфейс будет содержать динамический тип и потому не будет равен nil. Небезопасный вызов Error у такого указателя может привести к панике, если метод разыменовывает receiver.

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

Методовый набор ТипОшибки содержит методы, объявленные для значения, а *ТипОшибки содержит методы значения и методы, объявленные для указателя. Поэтому при указательной форме метода только *ТипОшибки реализует error.

package main

import (
	"errors"
	"fmt"
)

type ParseError struct{ Field string }
func (e *ParseError) Error() string { return "invalid " + e.Field }

func main() {
	var err error = &ParseError{Field: "email"}
	var target *ParseError
	fmt.Println(errors.As(err, &target), target.Field)
	// var wrong error = ParseError{Field: "email"} // ошибка компиляции
}

В примере &ParseError удовлетворяет error, а ParseError — нет. Для поиска конкретного типа через errors.As целевая переменная имеет тип *ParseError, поэтому в errors.As передаётся её адрес — &target; это адрес переменной, в которую функция запишет найденный указатель.

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

Не следует автоматически считать указательную форму безопаснее. Если вернуть nil-указатель как error, интерфейс не станет nil. Кроме того, метод Error должен либо корректно обрабатывать nil-receiver, либо такой случай нельзя допускать на границе API.

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

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

Значение проще концептуально и не создаёт проблем с nil-указателем, но копирует структуру при передаче через интерфейс. Указатель не копирует сам объект и удобен для errors.As, однако требует единообразно возвращать *ParseError и аккуратно обрабатывать nil.

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

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

Можно ли присвоить значение типа с указательным Error переменной error через адресуемую переменную?

Нет, обычная адресуемость переменной не меняет её статический тип. Неявное взятие адреса допустимо при вызове метода, но присваивание интерфейсу проверяет, реализует ли именно тип значения интерфейс; ТипОшибки его не реализует. Нужно явно передать *ТипОшибки.

Почему value receiver иногда предпочтительнее для пользовательской ошибки?

При value receiver и значение, и указатель на него удовлетворяют error, поэтому API допускает больше форм. Это подходит для маленьких неизменяемых структур и уменьшает риск случайного nil-указателя. Компромисс — возможное копирование структуры и менее очевидная семантика идентичности, особенно если внутри есть ссылочные поля.

Что произойдёт при errors.As, если ошибка возвращена значением, а метод Error объявлен для значения?

Тогда динамический тип ошибки — ТипОшибки, а не *ТипОшибки. Цель поиска должна соответствовать этому типу: переменная-цель имеет тип ТипОшибки, и в errors.As передаётся её адрес. Поиск *ТипОшибки такую ошибку не найдёт, поскольку errors.As не превращает значение в указатель и не угадывает желаемую форму.