为什么建议在 go 中返回 `error` 接口而不是具体的错误类型？

Question

go FQA状态：对于返回错误的函数，最好在其签名中始终使用错误类型（正如我们上面所做的那样），而不是像 *MyError 这样的具体类型，以帮助确保正确创建错误。例如，os.Open返回一个错误，即使不是 nil，它也总是具体类型*os.PathError。但是这篇文章声称有时返回一个具体的类型是可以的：（由于 Go FAQ 中讨论的原因，将错误的具体类型而不是错误传回通常是错误的，但在这里这样做是正确的，因为这ServeHTTP是唯一可以看到值并使用其内容的地方。）我的问题是，使用返回error而不是具体类型有什么好处，它如何帮助保证正确创建错误，以及为什么在不同地方不使用错误时返回具体类型是可以的？

Answer 1

这与error作为一个接口有关。一个接口包含一个指向它所包含的值的指针以及该值的类型。只有当这两个值都为 nil 时，接口才为 nil。所以，如果你从一个函数返回一个具体的错误类型，然后返回一个error，那个错误不会是 nil。

type MyError string

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

func f() *MyError {

  return nil

}

func g() error {

  return f()

}

func main() {

  x:=g()

  if x==nil {

    fmt.Println("nil")

  }

}

在上面的例子中，即使*MyErrorvalue 是 nil，返回值g()也不是，因为它包含一个 type*MyError和 value 为 nil 的接口。

这是所有返回接口值的函数的问题，并且最常见于error类型。所以不要声明返回具体错误值的函数，除非这些函数的用途非常有限，例如未导出的函数。