Risposta.

In Go, le interfacce fmt.Stringer ed error vengono utilizzate per gestire come un valore di struttura viene convertito in una stringa e come essa gestisce gli errori. Queste interfacce forniscono modi universali per il logging, l'output e la gestione degli errori, rendendo il codice più flessibile e chiaro.

Storia della domanda:

Dalle prime versioni di Go, l'interfaccia Stringer è diventata fondamentale per un output controllato e ben formattato delle strutture. L'interfaccia error si è rivelata fondamentale per la gestione degli errori a tutti i livelli del codice.

Problema:

Spesso i programmatori ottengono output poco informativi o messaggi di errore inaspettati perché non hanno implementato questi metodi o lo hanno fatto in modo non standard. Inoltre, un'implementazione errata può portare a output ricorsivi, panic e messaggi di errore illeggibili.

Soluzione:

Implementare il metodo String() string per le strutture se si desidera gestire la loro rappresentazione in fmt.Print*
Implementare Error() string per i tipi di errore personalizzati

Esempio di codice:

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) // chiama String()
    err := MyError{Msg:"fail"}
    fmt.Println(err) // chiama Error()
}

Caratteristiche chiave:

I metodi String() ed Error() vengono chiamati atomisticamente durante l'output o la scrittura nei log
L'implementazione di String() per gli errori può portare a ricorsione infinita se all'interno si richiama di nuovo fmt.Sprintf
La standardizzazione degli errori tramite Error() semplifica la gestione e la tracciatura

Domande trabocchetto.

È obbligatorio implementare String() o Error() come metodi valore o è possibile utilizzare puntatori?

Entrambe le opzioni sono valide, ma l'implementazione su receiver di puntatore e receiver di valore influisce sui tipi di oggetti sui quali il metodo funzionerà. Di solito si utilizza il receiver di puntatore per le strutture mutabili.

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

È possibile utilizzare fmt.Sprintf all'interno di String() o Error()?

Sì, ma è necessario prestare attenzione a non causare una ricorsione infinita (ad esempio, l'output di una struttura con lo stesso tipo all'interno di String()). Si consiglia di evitare di utilizzare fmt.Print all'interno di String() se verrà richiamato di nuovo String() internamente.

func (u User) String() string { return fmt.Sprintf("%v", u.Name) } // sicuro

Cosa succede se il metodo Error() restituisce una stringa vuota?

Gli errori con una stringa vuota vengono considerati valori error validi, ma il logging perde significato. L'interfaccia error non definisce il comportamento per una stringa vuota, ma è generalmente accettato fornire sempre un messaggio informativo.

Errori comuni e anti-patterns

Chiamata ricorsiva a fmt.Sprintf in String()
Perdita implicita di informazioni in Error()
Nomi di metodi stringa, ma non esportati (errore di sintassi)

Esempio dalla vita reale

Caso negativo

Un sviluppatore stampa una struttura tramite %+v, senza implementare String(), ottenendo così dump di campo confusi nei log.

Vantaggi:

Veloce, senza costi per un output gradevole

Svantaggi:

I log sono illeggibili, difficile da mantenere, brutto da vedere nell'output utente

Caso positivo

Il team leader costringe il team a implementare String() ed Error() per tutte le strutture pubbliche. Di conseguenza, la logica di business gestisce gli errori in modo centralizzato, e l'interfaccia amministrativa e i log di debug diventano leggibili.