Разберите результат: почему errors.Is не считает два значения с одинаковым содержимым одной ошибкой? пример...

package main

import (
	"errors"
	"fmt"
)

type ValidationErrors []string

func (e ValidationErrors) Error() string { return fmt.Sprint([]string(e)) }

func main() {
	a := ValidationErrors{"email"}
	b := ValidationErrors{"email"}
	fmt.Println(errors.Is(a, b))
}

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

Программа напечатает false. Тип ValidationErrors основан на срезе, поэтому его значения не comparable; errors.Is не выполняет для них сравнение через ==, даже если элементы срезов совпадают.

Чтобы задать смысловое равенство таких ошибок, нужно реализовать метод Is(error) bool либо сравнивать структурированные поля явно в коде обработчика. Одного совпадения текста, возвращаемого методом Error, недостаточно.

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

В Go ошибки являются значениями интерфейсного типа error, а не отдельным встроенным механизмом исключений. Начиная с Go 1.13 стандартная библиотека предоставляет errors.Is, errors.As и wrapping, чтобы обрабатывать причины ошибок структурно, без анализа текстовых сообщений.

При этом errors.Is сохраняет обычную семантику равенства там, где она безопасна и определена языком. Это позволяет сравнивать comparable-ошибки, но не навязывает автоматическое глубокое сравнение массивов, срезов или карт.

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

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

Если разработчик ожидает, что errors.Is автоматически выполнит глубокое сравнение, обработчик не распознает эквивалентную ошибку. Попытка самостоятельно привести значения к интерфейсам и сравнить их через == может привести к панике для динамически несравнимого типа.

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

Внутри errors.Is сначала проверяется, можно ли сравнивать значение цели напрямую. Для несравнимого типа этот путь пропускается, поэтому два значения ValidationErrors не сравниваются по содержимому. Метод Error() здесь не участвует: его текст предназначен для представления ошибки человеку, а не для определения её идентичности.

Для пользовательского смысла равенства реализуют Is:

func (e ValidationErrors) Is(target error) bool {
	t, ok := target.(ValidationErrors)
	if !ok || len(e) != len(t) {
		return false
	}
	for i := range e {
		if e[i] != t[i] {
			return false
		}
	}
	return true
}

После этого errors.Is(a, b) вызовет a.Is(b) и сможет использовать заданное правило. Реализация должна быть устойчивой к значениям других типов, не полагаться на текст ошибки и четко определять, важен ли порядок элементов, допускаются ли дубликаты и нужно ли сравнивать дополнительные поля.

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

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

Сервис валидирует пакет данных и возвращает ValidationErrors со срезом имён некорректных полей. Тест создает ожидаемое значение с тем же списком и вызывает errors.Is(actual, expected), но проверка не проходит.

Можно сравнивать строки из Error(), однако это хрупко: изменение формата сообщения сломает тест, а локализация или перестановка элементов может изменить текст без изменения смысла. Можно применить reflect.DeepEqual, но это связывает вызывающий код с внутренним представлением ошибки и не дает стандартным средствам обработки ошибок знания о семантике.

Лучшее решение — реализовать Is с явно документированным правилом сравнения. Если порядок полей не имеет значения, метод должен нормализовать или сравнивать их как множество; если порядок важен, это правило следует сохранить. В результате вызывающий код использует стабильный errors.Is, а внутреннее представление ошибки можно менять без распространения деталей по системе.

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

1. Может ли errors.Is вызвать панику на несравнимой ошибке?

   Обычно нет: перед прямым сравнением цели стандартная реализация проверяет, является ли её тип comparable. Для несравнимой цели сравнение через == пропускается, и поиск продолжается через пользовательский Is и wrapping. Однако ручное сравнение двух интерфейсов с динамическими несравнимыми значениями может привести к панике, поэтому полагаться на такую проверку вне errors.Is нельзя.

2. Достаточно ли реализовать Is только у указателя на тип ошибки?

   Нет, это зависит от того, какое представление реально передается как error. Если Is объявлен только у *ValidationError, а возвращается значение ValidationError, такой метод не будет доступен для данного значения. Нужно согласовать receiver метода с публичным способом создания и возврата ошибки; обычно изменяемые или крупные ошибки возвращают указатель, а небольшие неизменяемые значения могут использовать value receiver.

3. Должен ли Is сравнивать все поля ошибки?

   Не обязательно. Метод Is отвечает за вопрос: относится ли ошибка к той же категории или соответствует ли заданному признаку. Для sentinel-категории он может игнорировать диагностическое сообщение и вспомогательные данные; для ошибки валидации — сравнивать нормализованный набор полей. Главное — сделать правило стабильным, предсказуемым и не использовать Is как замену извлечению подробных данных через errors.As.