Quelle est la langue d'erreur ?

En langage Go, eof fait référence à l'erreur de fin de fichier. C'est la variable d'erreur la plus importante en langage Go. Elle existe dans le package io et est utilisée pour indiquer la fin du flux d'entrée. Parce que chaque fichier a une fin, "io.EOF" n'est souvent pas considéré comme une erreur. Il est plus important d'indiquer la fin d'un flux d'entrée.

L'environnement d'exploitation de ce tutoriel : système Windows 7, GO version 1.18, ordinateur Dell G3. Les fonctions

golang end-of-file (EOF)

renvoient souvent plusieurs erreurs, ce qui peut être intéressant pour l'utilisateur final, mais complique la situation pour le programme. Souvent, les programmes doivent réagir différemment selon le type d’erreur. Prenons un exemple :

Lire n octets d'un fichier. Si n est égal à la longueur du fichier, toute erreur dans le processus de lecture indique un échec. Si n est inférieur à la longueur du fichier, l'appelant lira à plusieurs reprises les données de taille fixe jusqu'à la fin du fichier. Cela oblige l'appelant à gérer séparément diverses erreurs causées par la fin du fichier.

Pour cette raison, io包garantissez que tout échec de lecture provoqué par la fin du fichier renvoie la même erreur - io.EOF, qui est définie dans le package io :

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

Comprenez io.EOF

io. EOF est une variable du package io, indiquant l'erreur de fin de fichier :

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

Consultez également la documentation détaillée via la commande suivante :

$ 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 est probablement la variable d'erreur la plus importante dans le langage Go, elle est utilisée pour représente la fin du flux d'entrée. Parce que chaque fichier a une fin, io.EOF n'est pas une erreur dans de nombreux cas. Il est plus important d'indiquer la fin d'un flux d'entrée.

Défauts de conception de io.EOF

Malheureusement, la conception de io.EOF dans la bibliothèque standard est problématique Tout d'abord, EOF est l'abréviation de End-Of-File selon l'habitude du langage Go. , l'abréviation des lettres majuscules signifie généralement Constant. Malheureusement, io.EOF a été mal défini en tant que variable, ce qui a conduit à la prolifération des autorisations API. La réduction des autorisations API est l'exigence la plus élevée pour toute conception de module ou de fonction. dans le code peut être découvert le plus tôt possible.

Par exemple, une conception de sécurité importante du langage Go consiste à interdire la conversion de type implicite. Par conséquent, avec cette conception, nous pouvons facilement trouver des bogues dans le programme. De plus, le langage Go interdit la définition de variables locales inutilisées (les paramètres de fonction (sauf que les paramètres de fonction font partie de l'interface de fonction) et l'interdiction de l'importation de packages inutilisés sont de bonnes pratiques pour minimiser les autorisations. La conception de ces autorisations API minimales non seulement améliore la qualité du programme, mais améliore également les performances des outils de compilation. Performances et fichiers cibles de sortie.

Étant donné que EOF est défini comme une variable, cette variable peut être modifiée de manière malveillante. Le code suivant est une manière élégante d'enterrer le. trap:

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

Bien que ce soit une blague, mais cela a vraiment révélé les défauts de conception de l'interface EOF : elle présente de sérieux risques de sécurité. Le type des variables semble également impliquer que l'utilisateur peut modifier en toute sécurité la valeur de la variable.

io.EOF est remplacé par une constante

Une idée d'amélioration évidente est de définir io.EOF comme une constante, car EOF correspond à une interface d'erreur. type, et la syntaxe constante actuelle du langage Go ne prend pas en charge la définition des types de constantes Interface Mais nous pouvons utiliser quelques astuces pour contourner cette limitation

Les constantes du langage Go ont les principaux types de bool/int/float/. string/nil. Non seulement les constantes n'incluent pas de types complexes tels que les interfaces, mais également les tableaux de constantes. Ni les structures ni les structures ne sont prises en charge. Cependant, il existe une règle d'extension importante pour les constantes : les nouveaux types définis avec bool/int/float/. string/nil en tant que type de base prend également en charge les constantes.

Par exemple, si nous redéfinissons un type de chaîne, il peut également prendre en charge les constantes :

type MyString string2const name MyString = "chai2010"

Dans cet exemple, MyString est un type nouvellement défini, et les constantes de ce type peuvent être défini car son type de chaîne sous-jacent prend en charge les constantes.

Ensuite, le type sous-jacent de io.EOF est Quoi ? EOF est défini via des erreurs.New("EOF") Voici l'implémentation de cette fonction :

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
}

Donc le. Le type sous-jacent de io.EOF est la structure erreurs.errorString. Le type de structure ne prend pas en charge la définition de constantes. Cependant, il n'y a qu'un seul type de chaîne dans la structure erreurs.errorString et la chaîne d'erreur correspondant à io.EOF est "EOF". .

Nous pouvons réimplémenter un nouveau type d'erreur pour EOF avec une chaîne comme type sous-jacent :

package io

type errorString string

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

Ce nouveau io.errorString implémente deux fonctionnalités : premièrement, il satisfait l'interface d'erreur, deuxièmement, il est redéfini en fonction de la chaîne ; type, il prend donc en charge la définition de constantes. Par conséquent, nous pouvons redéfinir io.EOF comme une constante basée sur errorString:

const EOF = errorString("EOF")

De cette façon, EOF devient un type constant qui peut être déterminé au moment de la compilation et la valeur du constant est toujours la chaîne "EOF". Mais cela amène aussi de nouveaux problèmes : EOF n'est plus un type d'interface, et cela détruira l'ancien code Compatibilité ?

【Recommandations associées : Tutoriel vidéo Go, Enseignement de la programmation】

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!