Ответ.

В Go интерфейсы fmt.Stringer и error используются для управления тем, как значение структуры приводит к строке и как она реализует ошибку соответственно. Эти интерфейсы обеспечивают универсальные способы логирования, вывода и работы с ошибками, делая код гибче и понятнее.

История вопроса:

С первых версий Go интерфейс Stringer стал ключевым для красиво-контролируемого вывода структуры. Интерфейс error оказался фундаментальным для обработки ошибок на всех уровнях кода.

Проблема:

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

Решение:

Реализовать метод String() string для структур, если нужно управлять их представлением в fmt.Print*
Реализовать Error() string для пользовательских типов ошибок

Пример кода:

package main
import "fmt"

type User struct {
    Name string
    ID   int
}

func (u User) String() string {
    return fmt.Sprintf("User<%d:%s>", u.ID, u.Name)
}

type MyError struct {
    Msg string
}

func (e MyError) Error() string { return "MyError: " + e.Msg }

func main() {
    u := User{Name: "Bob", ID: 10}
    fmt.Println(u) // вызывает String()
    err := MyError{Msg:"fail"}
    fmt.Println(err) // вызывает Error()
}

Ключевые особенности:

Методы String() и Error() вызываются атомарно при выводе или записи в логи
Реализация ошибочного String() может привести к бесконечной рекурсии, если внутри снова вызывается fmt.Sprintf
Стандартизация ошибок через Error() упрощает обработку и трассировку

Вопросы с подвохом.

Обязательно ли реализовывать String() или Error() как методы-значения или можно использовать указатели?

Оба варианта допустимы, но реализация на pointer-receiver и value-receiver влияет на то, на каких типах объектов метод сработает. Обычно используют pointer-receiver для мутабельных структур.

func (u *User) String() string {...}

Можно ли использовать fmt.Sprintf внутри String() или Error()?

Да, но нужно внимательно следить, чтобы не вызвать бесконечную рекурсию (например, вывод структуры с тем же типом внутри String()). Рекомендуется избегать использования fmt.Print внутри String(), если внутренне снова будет вызван String().

func (u User) String() string { return fmt.Sprintf("%v", u.Name) } // безопасно

Что произойдет, если метод Error() возвращает пустую строку?

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

Типовые ошибки и анти-паттерны

Рекурсивный вызов fmt.Sprintf в String()
Неявная потеря информации в Error()
Имена методов строковые, но не экспортируются (ошибка синтаксиса)

Пример из жизни

Негативный кейс

Разработчик выводит структуру через %+v, не реализовав String(), в результате получая мусорные дампы полей в логах.

Плюсы:

Быстро, без затрат на симпатичный вывод

Минусы:

Логи нечитабельны, тяжело поддерживать, некрасиво смотрится на пользовательском выводе

Позитивный кейс

Тимлид заставляет команду реализовать String() и Error() для всех публичных структур. В результате бизнес-логика обрабатывает ошибки централизованно, а админка и дебаг-логи становятся читаемыми.