Обработка ошибок

Сетевой вызов завершился ошибкой контекста: как вызывающему отличить отмену операции от истечения дедлайна без анализа текста ошибки?

В middleware безусловно преобразуют значение из recover в error. Какой риск возникает при таком проектировании?

Какой результат вернёт fmt.Errorf с единственным %w и аргументом nil?

Как выбрать между sentinel-ошибкой и типизированной ошибкой при проектировании публичного API Go?

Вызов recover вынесен из deferred-функции во вспомогательный метод: почему паника не будет перехвачена?

У функции с именованным результатом есть deferred-восстановление после panic: какое значение она вернёт, если обработчик изменит этот результат?

Сервис напрямую отправляет клиенту текст любой ошибки: какое свойство дизайна ошибок нужно обеспечить, чтобы внутренние детали не стали частью внешнего контракта?

Разберите результат: почему 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))
}

Ошибка должна предоставлять дополнительное поведение через интерфейс, но её конкретный тип неизвестен: каким механизмом Go это обнаружить?

При агрегировании результатов нескольких операций какое значение возвращает errors.Join, если все переданные ошибки равны nil?

Можно ли в другом deferred-обработчике повторно получить ту же панику после успешного recover?

В цепочке обёрток две ошибки одного типа. Какую ошибку получит errors.As?

package main

import (
	"errors"
	"fmt"
)

type tagged struct { name string; cause error }
func (e *tagged) Error() string { return e.name }
func (e *tagged) Unwrap() error { return e.cause }

func main() {
	inner := &tagged{name: "inner"}
	outer := &tagged{name: "outer", cause: inner}
	var got *tagged
	errors.As(outer, &got)
	fmt.Println(got.name)
}

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

В публичном пакете sentinel-ошибка объявлена экспортируемой переменной: какой риск для корректности errors.Is создаёт её переназначение?

Что вернёт errors.Is, если искомая ошибка равна nil, а проверяемая ошибка ненулевая и имеет собственный метод Is?

Как меняется семантика обёртки ошибки, если форматирование содержит несколько спецификаторов %w?

Представьте обработчик, который ищет конкретный тип ошибки. Какой контракт аргумента target нарушен в этом фрагменте и какое последствие возникнет?

package main

import (
	"errors"
	"fmt"
)

type quotaError struct{}
func (*quotaError) Error() string { return "quota exceeded" }

func main() {
	var target *quotaError
	fmt.Println(errors.As(&quotaError{}, target))
}

В многослойном Go-сервисе каждый слой добавляет контекст к одной ошибке: на каком уровне её обычно следует логировать, чтобы не получить дублирование и не потерять диагностику?

Что позволяет пользовательскому типу ошибки изменить результат errors.As без совпадения конкретного типа?

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