Was ist der Go-Language-Eof-Fehler?

In der Go-Sprache bezieht sich eof auf den End-of-File-Fehler. Es ist die wichtigste Fehlervariable in der Go-Sprache. Sie existiert im io-Paket und wird verwendet, um das Ende des Eingabestreams anzuzeigen. Da jede Datei ein Ende hat, wird „io.EOF“ oft nicht als Fehler betrachtet. Es ist wichtiger, das Ende eines Eingabestreams anzuzeigen.

Die Betriebsumgebung dieses Tutorials: Windows 7-System, GO Version 1.18, Dell G3-Computer.

golang End-of-File (EOF)

Funktionen geben oft mehrere Fehler zurück, was für den Endbenutzer interessant sein kann, die Situation für das Programm jedoch verkompliziert. Oftmals müssen Programme je nach Fehlerart unterschiedlich reagieren. Betrachten wir ein Beispiel:

Lesen Sie n Bytes aus einer Datei. Wenn n gleich der Länge der Datei ist, weist jeder Fehler beim Lesevorgang auf einen Fehler hin. Wenn n kleiner als die Länge der Datei ist, liest der Aufrufer wiederholt Daten fester Größe bis zum Ende der Datei. Dies führt dazu, dass der Aufrufer verschiedene Fehler, die durch das Dateiende verursacht werden, separat behandeln muss.

Aus diesem Grund io包garantieren wir, dass jeder durch das Ende der Datei verursachte Lesefehler denselben Fehler zurückgibt – io.EOF, der im io-Paket definiert ist:

package io
import "errors"
// EOF is the error returned by Read when no more input is available.
var EOF = errors.New("EOF")

Verstehen Sie io.EOF

io. EOF ist eine Variable im io-Paket, die den Dateiendefehler angibt:

package io23var EOF = errors.New("EOF")

Sehen Sie sich auch die detaillierte Dokumentation mit dem folgenden Befehl an:

$ go doc io.EOF
var EOF = errors.New("EOF")
EOF is the error returned by Read when no more input is available. Functions
should return EOF only to signal a graceful end of input. If the EOF occurs
unexpectedly in a structured data stream, the appropriate error is either
ErrUnexpectedEOF or some other error giving more detail.
$

io.EOF ist wahrscheinlich die wichtigste Fehlervariable in der Go-Sprache, an die man gewöhnt ist stellt das Ende des Eingabestreams dar. Da jede Datei ein Ende hat, ist io.EOF in vielen Fällen kein Fehler. Es ist wichtiger, das Ende eines Eingabestreams anzuzeigen.

io.EOF-Designfehler

Leider ist das Design von io.EOF in der Standardbibliothek problematisch. Erstens ist EOF die Abkürzung für End-Of-File , die Abkürzung bedeutet im Allgemeinen „Konstante“. Leider wurde io.EOF fälschlicherweise als Variable definiert, was zur Minimierung von API-Berechtigungen bei jedem Modul- oder Funktionsdesign führte Notwendige Fehler können so früh wie möglich erkannt werden.

Ein wichtiges Sicherheitsdesign der Go-Sprache besteht beispielsweise darin, implizite Typkonvertierungen zu verhindern Darüber hinaus verbietet die Go-Sprache die Definition nicht verwendeter lokaler Variablen (Funktionsparameter (mit der Ausnahme, dass Funktionsparameter Teil der Funktionsschnittstelle sind) und das Verbot des Imports nicht verwendeter Pakete sind Best Practices zur Minimierung von Berechtigungen. Das Design dieser minimalen API-Berechtigungen ist nicht nur das Verbessert die Qualität des Programms, verbessert aber auch die Leistung der Kompilierungstools und der Ausgabezieldateien. Da EOF als Variable definiert ist, kann diese Variable böswillig geändert werden. Der folgende Code ist eine elegante Möglichkeit, die zu verbergen trap:

func init() {2    io.EOF = nil3}

Das ist zwar ein Witz, aber es hat wirklich die Designfehler der EOF-Schnittstelle aufgedeckt: Sie birgt ernsthafte Sicherheitsrisiken. Der Typ der Variablen scheint auch zu implizieren, dass der Benutzer den Wert der Variablen sicher ändern kann Daher ist EOF ein unsicheres und elegantes Design Typ, und die aktuelle Konstantensyntax der Go-Sprache unterstützt die Definition von Konstantentypen. Schnittstelle. Wir können jedoch einige Tricks verwenden, um diese Einschränkung zu umgehen.

Go-Sprachkonstanten haben die Haupttypen bool/int/float/string/nil Konstanten umfassen nicht nur keine komplexen Typen wie Schnittstellen, sondern auch Arrays von Konstanten. Es gibt jedoch eine wichtige Erweiterungsregel für Konstanten: Neue Typen, die mit bool/int/float/string/nil definiert werden Der Basistyp unterstützt auch Konstanten.

Wenn wir beispielsweise einen String-Typ neu definieren, kann er auch Konstanten unterstützen:

type MyString string2const name MyString = "chai2010"

In diesem Beispiel ist MyString ein neu definierter Typ, und Konstanten dieses Typs können definiert werden, weil er Der zugrunde liegende Zeichenfolgentyp unterstützt Konstanten. Dann ist der zugrunde liegende Typ von io.EOF Was? .EOF ist die Struktur „errors.errorString“. Es gibt jedoch nur einen String-Typ in der Struktur „errors.EOF“. kann einen neuen Fehlertyp für EOF mit String als zugrunde liegendem Typ neu implementieren:

package errors 
// New returns an error that formats as the given text. 
func New(text string) error {
    return &errorString{text} 
} 

// errorString is a trivial implementation of error. 
type errorString struct {
    s string
}

func (e *errorString) Error() string {
    return e.s
}

Dieser neue io.errorString implementiert zwei Funktionen: Erstens erfüllt er die Fehlerschnittstelle; zweitens wird er basierend auf dem String-Typ neu definiert unterstützt die Definition von Konstanten. Daher können wir io.EOF als Konstante basierend auf errorString:

package io

type errorString string

func (e errorString) Error() string {
    return string(e)
}

neu definieren. Auf diese Weise wird EOF zu einem Konstantentyp, der zur Kompilierungszeit bestimmt werden kann, und der Wert der Konstante bleibt erhalten „EOF“-Zeichenfolge bringt aber auch neue Probleme mit sich: EOF ist kein Schnittstellentyp mehr und zerstört den alten Code. Kompatibilität?

【Verwandte Empfehlungen: Go-Video-Tutorial, Programmierunterricht】

Das obige ist der detaillierte Inhalt vonWas ist der Go-Language-Eof-Fehler?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!