go1.13에서 errors 패키지의 Is와 As 방법

비록 지금은 go1.14가 되었지만 go1.13에 도입된 error의 처리 방법을 생각해 냈다.
먼저 goblog에 링크를 넣습니다: go1.13-errors 이 블로그는 이전에 error 유형 처리 방법에 대해 논술했습니다. 우리는 자주 error를 처리할 때 유용한 상하문 정보를 추가해야 합니다. 이전에 자주 사용한 방법은 github.com/pkg/errors 이 가방에 있는 errors.WithMessage 방법 또는 errors.WithStack 방법을 사용했습니다.결과 err에서 원시 error를 얻으려면 err.Cause() 방법을 호출합니다.
그러나 이렇게 하면 문제가 하나 있다. 만약에 error가 너무 깊게 감싸면 한 겹 한 겹 뜯어서 검사할 수 밖에 없다는 것이다.
하지만 걱정하지 마세요. go1.13에 새로 나온 errors 패키지가 이 문제를 해결했습니다.이것은 errors.Is와 errors.As 두 가지 방법을 추가하여 error를 처리합니다.
구체적인 사용 방법은 이 글을 참고하십시오. Go 1.13의 오류 처리
나의 이 박문에서 주로 밟은 구덩이, 즉 errors.As 방법 중의 두 번째 파라미터, 즉 target을 강조하고 싶다.함수 성명에서 target은 빈 인터페이스로 임의의 형식을 전달할 수 있습니다.그러나 As 함수의 정의에 따르면 target는 반드시 실현된 error 인터페이스를 가리키는 바늘이어야 한다는 것을 알 수 있다. (만약 당신이 jetbrains의 IDE를 사용한다면 편집기에서 알려줄 것이다.)
바로 여기서 작은 문제가 발생할 수 있다. 만약에 Foo 유형 구조체가 있다면 Error() 방법을 실현했지만 이 방법의 수신자는 지침 유형이다. 즉,

type Foo struct{}

func (f *Foo) Error() string {
    return "this is an foo error"
}

이렇게 하면 사실Foo과 *Foo은 모두 error 인터페이스이다.그래서 만약에 되돌아오는 err 유형이 *Foo 유형이고 당신의 코드는 이렇게 적혀 있습니다.

func Bar() {
    err := someFuncReturnPointerFoo() // *Foo
    var tErr Foo
    fmt.Println(errors.As(err, &tErr))
    // Output: false
}

err를 Foo 유형으로 처리하기를 기대하며 컴파일은 통과할 수 있으나 원하는 결과를 얻을 수 없습니다.tErr유형은 Foo유형이고, err실제로는 *Foo유형이기 때문이다.따라서 우리는 위 코드의 세 번째 줄, 성명tErr의 위치를 *Foo로 바꾸면 된다.