Go 言語では、eof はファイルの終わりのエラーを指します。これは Go 言語で最も重要なエラー変数です。io パッケージに存在し、入力ストリームの終わりを示すために使用されます。すべてのファイルには終わりがあるため、「io.EOF」はエラーとは見なされないことがよくありますが、入力ストリームの終わりを示すことの方が重要です。
このチュートリアルの動作環境: Windows 7 システム、GO バージョン 1.18、Dell G3 コンピューター。
golang ファイルの終わりエラー (EOF)
関数は複数のエラーを返すことがよくあり、これはエンド ユーザーにとって興味深い場合がありますが、プログラムの場合は、これが状況を複雑にしています。多くの場合、プログラムはエラーの種類に応じて異なる対応をする必要があります。例を考えてみましょう:
ファイルから n バイトを読み取ります。 n がファイルの長さと等しい場合、読み取りプロセスのエラーは失敗を示します。 n がファイルの長さより小さい場合、呼び出し元はファイルの終わりまで固定サイズのデータを繰り返し読み取ります。その結果、呼び出し元はファイルの終わりによって引き起こされるさまざまなエラーを個別に処理する必要があります。
このため、io パッケージ
では、ファイルの終わりによって読み取りエラーが発生した場合には、io パッケージで定義されている同じエラー io.EOF が返されるようにします。
package io import "errors" // EOF is the error returned by Read when no more input is available. var EOF = errors.New("EOF")
io.EOF
io.EOF は io パッケージ内の変数であり、ファイルの終わりエラーを示します:
package io23var EOF = errors.New("EOF")
また、次のコマンドを使用して詳細なドキュメントを参照してください:
$ 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 は、おそらく Go 言語で最も重要なエラー変数です。これは、入力ストリームの終わりを示すために使用されます。 end、io.EOF は多くの場合エラーではありませんが、入力ストリームの終わりを示すことの方が重要です。
io.EOF の設計の欠陥
残念ながら、標準ライブラリの io.EOF の設計には問題があります。 , EOF は End- Of-File の略語です。Go 言語の規則によれば、通常、大文字の略語は定数を表します。残念ながら、io.EOF は誤って変数として定義され、API 権限の急増につながりました。API の最小化アクセス許可は、モジュールまたは関数の設計です。最も高い要件です。アクセス許可を最小限に抑えることで、コード内の不要なエラーをできるだけ早く発見できます。
たとえば、Go 言語の重要なセキュリティ設計は次のとおりです。暗黙的な型変換を禁止するため、この設計により、プログラムのバグを簡単に発見できます。さらに、Go 言語では、未使用のローカル変数の定義が禁止されています (関数パラメーターを除くため、関数パラメーターは関数インターフェイスの一部です)。未使用のパッケージのインポート (権限を最小限に抑えるためのベスト プラクティス)。これらの最小限の API 権限の設計により、プログラムの品質が向上するだけでなく、コンパイル ツールと出力ターゲット ファイルのパフォーマンスも向上します。
EOF は変数として定義されているため、変数が悪意を持って変更されます。次のコードは、トラップを埋めるための洗練された方法です:
func init() {2 io.EOF = nil3}
これは冗談ですが、実際に EOF の設計上の欠陥を明らかにしています。 EOF インターフェイス: 重大なセキュリティ リスクがあります 変数の型 また、ユーザーが変数の値を安全に変更できることを暗示しているように見えます。したがって、EOF は安全ではなくエレガントな設計です。
io.EOF は定数に変更されます
明らかな改善案は、io.EOF を定数として定義することです。ただし、EOF はエラー インターフェイス タイプに対応しており、現在の定数構文は変わりません。 Go 言語の定数は、定数型のインターフェイスの定義をサポートしていません。しかし、この制限を回避するにはいくつかのトリックがあります。
Go 言語の定数には、bool/int/float/string/ の主な型があります。 nil. 定数には、インターフェイスなどの複合型だけでなく、定数の配列や構造体も含まれません。本体はサポートされていません! ただし、定数には重要な拡張規則があります: bool/int/float/string/ で定義された新しい型基本型の nil は定数もサポートします。
たとえば、文字列型を再定義すると、定数もサポートできます:
type MyString string2const name MyString = "chai2010"
この例では、MyString は新しく定義された型であり、定数
では、io.EOF の基礎となる型は何ですか? EOF は、errors.New("EOF") を通じて定義されます。以下は、その実装です。この関数:
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 }
したがって、io.EOF の基礎となる型は、errors .errorString 構造体です。この構造体型は定数の定義をサポートしていません。ただし、errors.errorString 構造体には文字列型が 1 つだけあり、 io.EOF に対応するエラー文字列は "EOF" です。
We 基礎となる型として string を持つ新しいエラー型は、EOF 用に再実装できます:
package io type errorString string func (e errorString) Error() string { return string(e) }
この新しい io.errorString は実装します。 2 つの特徴: 1 つ目は、エラー インターフェイスを満たすこと、2 つ目は、文字列型定義に基づいて再実装されるため、定数の定義をサポートすることです。したがって、io.EOF を errorString に基づいて定数として再定義できます:
const EOF = errorString("EOF")
このようにして、EOF はコンパイル時に決定できる定数型になり、定数の値は "EOF" String のままですが、新たな問題も生じます: EOF はもはやインターフェイス型ではありません。古いコードの互換性を破壊しますか?
【関連する推奨事項: Go ビデオ チュートリアル 、プログラミング教育 ]
以上がGo言語のeofエラーとは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。