為什么建議返回 go 中的 `error` 接口而不是具體的錯誤類型？

Question

go FQA狀態：

對於返回錯誤的函數，最好在其簽名中始終使用錯誤類型（正如我們上面所做的那樣），而不是像 *MyError 這樣的具體類型，以幫助確保正確創建錯誤。 例如， os.Open返回一個錯誤，即使不是 nil，它也總是具體類型*os.PathError 。

但是這篇文章聲稱有時返回一個具體的類型是可以的：

（由於 Go 常見問題解答中討論的原因，將錯誤的具體類型而不是錯誤傳回通常是錯誤的，但在這里這樣做是正確的，因為ServeHTTP是唯一可以看到該值並使用其內容的地方。）

我的問題是，返回error而不是具體類型有什么好處，它如何幫助保證正確創建錯誤，以及為什么在不同地方不使用錯誤時返回具體類型是可以的？

Answer 1

這與作為接口的error有關。 一個接口包含一個指向它所包含的值的指針以及該值的類型。 只有當這兩個值都為 nil 時，接口才為 nil。 因此，如果您從 function 返回一個具體的錯誤類型，然后返回一個error ，則該錯誤不會為零。

住在 Go 操場上

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")
  }
}

在上面的示例中，即使*MyError的值為 nil，但g()的返回值卻不是，因為它包含一個類型為*MyError且值為 nil 的接口。

這是所有返回接口值的函數的問題，並且最常見於error類型。 所以不要聲明返回具體錯誤值的函數，除非這些函數的用途非常有限，例如未導出的函數。