Warum ist der Schnittstellenwert „nil' in Go nicht gleich „error(nil)'?

Vergleich von Nil-Schnittstelleninstanzen

Bedenken Sie den folgenden Code:

<code class="go">type Goof struct {}

func (goof *Goof) Error() string {
    return fmt.Sprintf("I'm a goof")
}

func TestError(err error) {
    if err == nil {
        fmt.Println("Error is nil")
    } else {
        fmt.Println("Error is not nil")
    }
}

func main() {
    var g *Goof // nil
    TestError(g) // Displays "Error is not nil"
}</code>

Überraschenderweise führt dieser Code zu „ „Fehler ist nicht Null“, trotz der Absicht, auf die Null-Bedingung zu testen.

Der Schlüssel zum Verständnis dieses Verhaltens liegt in der Art und Weise, wie Go Schnittstellen implementiert. Intern bestehen Schnittstellenwerte aus einem Typ und einem Wert. Während der Wert Null sein kann, ist der Typ niemals Null. Im gegebenen Beispiel ist (*Goof)(nil) ein Schnittstellenwert mit dem Typ „*Goof“ und dem Nullwert.

Der Fehlerschnittstellentyp unterscheidet sich jedoch vom Typ „*Goof“. Daher sind (*Goof)(nil) und error(nil) nicht gleich, obwohl sie beide Nullwerte enthalten. Dies geht aus dem folgenden Code hervor:

<code class="go">var g *Goof // nil
var e error = g

if e == nil {
    fmt.Println("Error is nil")
} else {
    fmt.Println("Error is not nil")
}
// Output: Error is not nil</code>

Um dieses Problem zu beheben, gibt es mehrere Ansätze:

1. Deklarieren Sie var err error anstelle von var g *Goof, da err Null ist Der Wert ist praktischerweise error(nil).
2. Wenn die Funktion einen Fehler zurückgibt, wird mit return nil der gewünschte Null-Schnittstellenwert zurückgegeben.

Das obige ist der detaillierte Inhalt vonWarum ist der Schnittstellenwert „nil' in Go nicht gleich „error(nil)'?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!