go 언어 eof 오류는 무엇입니까?

go 언어에서 eof는 파일 끝 오류를 의미합니다. Go 언어에서 가장 중요한 오류 변수로 io 패키지에 존재하며 입력 스트림의 끝을 나타내는 데 사용됩니다. 모든 파일에는 끝이 있기 때문에 "io.EOF"는 오류로 간주되지 않는 경우가 많습니다. 입력 스트림의 끝을 나타내는 것이 더 중요합니다.

이 튜토리얼의 운영 환경: Windows 7 시스템, GO 버전 1.18, Dell G3 컴퓨터.

golang EOF(end-of-file)

함수는 종종 여러 오류를 반환하는데, 이는 최종 사용자에게는 흥미로울 수 있지만 프로그램의 상황을 복잡하게 만듭니다. 프로그램은 오류 유형에 따라 다르게 반응해야 하는 경우가 많습니다. 예를 들어 보겠습니다.

파일에서 n바이트를 읽습니다. n이 파일 길이와 같은 경우 읽기 프로세스에 오류가 있으면 실패를 나타냅니다. n이 파일 길이보다 작으면 호출자는 파일 끝까지 고정 크기 데이터를 반복해서 읽습니다. 이로 인해 호출자는 파일 끝으로 인해 발생하는 다양한 오류를 별도로 처리해야 합니다.

이러한 이유로 io包파일 끝으로 인한 모든 읽기 실패는 io 패키지에 정의된 io.EOF와 같은 오류를 반환하도록 보장합니다. EOF는 파일 끝 오류를 나타내는 io 패키지의 변수입니다.

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

또한 다음 명령을 통해 자세한 문서를 확인하세요.

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

io.EOF는 아마도 Go 언어에서 가장 중요한 오류 변수일 것입니다. 입력 스트림의 끝을 나타냅니다. 모든 파일에는 끝이 있으므로 io.EOF는 대부분의 경우 오류가 아닙니다. 입력 스트림의 끝을 나타내는 것이 더 중요합니다.

io.EOF 디자인 결함

안타깝게도 표준 라이브러리의 io.EOF 디자인은 우선 Go 언어의 습관에 따르면 End-Of-File의 약어입니다. , 대문자의 약어는 일반적으로 Constant를 의미합니다. 불행히도 io.EOF는 변수로 잘못 정의되어 API 권한이 급증했습니다. API 권한을 최소화하는 것은 권한, 불규칙성을 최소화하는 것입니다. 코드에서 필요한 오류를 가능한 한 빨리 발견할 수 있습니다.

예를 들어 Go 언어의 중요한 안전 설계는 암시적 유형 변환을 금지하는 것입니다. 따라서 이 설계를 사용하면 프로그램에서 버그를 쉽게 찾을 수 있습니다. 또한 Go 언어는 사용되지 않는 지역 변수(함수 매개변수(함수 매개변수가 함수 인터페이스의 일부인 경우 제외)의 정의를 금지하고 사용하지 않는 패키지 가져오기를 금지하는 것은 권한을 최소화하기 위한 모범 사례입니다. 이러한 최소 API 권한의 설계는 뿐만 아니라 프로그램의 품질도 향상되지만 컴파일 도구의 성능도 향상됩니다.EOF는 변수로 정의되어 있으므로 이 변수는 악의적으로 변경될 수 있습니다. Trap:

$ 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.
$

농담이긴 하지만 실제로는 EOF 인터페이스의 설계 결함이 드러났습니다. 변수 유형도 사용자가 변수 값을 안전하게 수정할 수 있음을 암시하는 것 같습니다. .따라서 EOF는 안전하지 않고 우아한 디자인입니다.

io.EOF는 상수로 변경됩니다

분명한 개선 아이디어는 io.EOF를 상수로 정의하는 것입니다. 왜냐하면 EOF는 오류 인터페이스에 해당하기 때문입니다. Go 언어의 현재 상수 구문은 상수 유형 인터페이스의 정의를 지원하지 않습니다. 하지만 몇 가지 트릭을 사용하여 이 제한을 우회할 수 있습니다.

Go 언어의 상수에는 bool/int/float/라는 주요 유형이 있습니다. 문자열/nil. 상수에는 인터페이스와 같은 복잡한 유형뿐만 아니라 상수 배열도 포함됩니다. 구조나 구조는 모두 지원되지 않습니다. 그러나 상수에 대한 중요한 확장 규칙이 있습니다: bool/int/float/로 정의되는 새로운 유형입니다. string/nil은 기본 유형으로 상수도 지원합니다.예를 들어 문자열 유형을 재정의하면 상수도 지원할 수 있습니다.

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

이 예에서 MyString은 새로 정의된 유형이며 이 유형의 상수는 기본 문자열 유형이 상수를 지원하기 때문에 정의됩니다.

그럼 io.EOF의 기본 유형은 오류를 통해 정의됩니다.New("EOF") 다음은 이 함수의 구현입니다.

type MyString string2const name MyString = "chai2010"

그래서 io.EOF의 기본 유형은 오류.errorString 구조입니다. 그러나 오류.errorString 구조에는 문자열 유형이 하나만 있으며 io.EOF에 해당하는 오류 문자열은 "EOF"입니다. .

문자열을 기본 유형으로 사용하여 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.errorString은 두 가지 기능을 구현합니다. 첫째, 오류 인터페이스를 충족하고, 둘째, 문자열을 기반으로 재정의됩니다. type이므로 상수 정의를 지원합니다. 따라서 io.EOF를 errorString:

package io

type errorString string

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

을 기반으로 하는 상수로 재정의할 수 있습니다. 이렇게 하면 EOF는 컴파일 타임에 결정될 수 있는 상수 유형이 되며, 상수는 여전히 "EOF" 문자열이지만 새로운 문제도 발생합니다. EOF는 더 이상 인터페이스 유형이 아니며 이전 코드 호환성을 파괴합니다.

【관련 추천: Go 비디오 튜토리얼, 프로그래밍 교육】

위 내용은 go 언어 eof 오류는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!