Go中error類型的nil值和nil

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

先看C語言中的類似問題：Null 字元串。

const char* empty_str0 = "";const char* empty_str1 = "\0empty";const char* empty_str2 = NULL;

以上3個字串並不相等，但是從某種角度看，它們都是對應空的字串。

• empty_str0 指向一個空的字串，但是empty_str0本身的值是有效。
• empty_str1 指向一個非空的字串，但是字串的第一個字元是'\0'。
• empty_str2 本身是一個空的指標。

Go的error是一個interface類型，error的nil問題和C語言的字串類似。

參考官方的error文檔說明：

• http://golang.org/doc/go_faq.html#nil_error

在底層，interface作為兩個成員實現：一個類型和一個值。該值被稱為介面的動態值， 它是一個任意的具體值，而該介面的類型則為該值的類型。對於 int 值3， 一個介面值示意性地包含(int, 3)。

只有在內部值和類型都未設定時(nil, nil)，一個介面的值才為 nil。特別是，一個 nil 介面將總是擁有一個 nil 類型。若我們在一個介面值中儲存一個 int 類型的指標，則內部類型將為 int，無論該指標的值是什麼：(*int, nil)。 因此，這樣的介面值會是非 nil 的，即使在該指標的內部為 nil。

下面是一個錯誤的錯誤返回方式：

func returnsError() error {    var p *MyError = nil    if bad() {        p = ErrBad    }    return p // Will always return a non-nil error.}

這裡 p 返回的是一個有效值（非nil），值為 nil。
類似上面的 empty_str0。

因此，下面判斷錯誤的代碼會有問題：

func main() {    if err := returnsError(); err != nil {        panic(nil)    }}

針對 returnsError 的問題，可以這樣處理（不建議的方式）：

func main() {    if err := returnsError(); err.(*MyError) != nil {        panic(nil)    }}

在判斷前先將err轉型為*MyError，然後再判斷err的值。
類似的C語言Null 字元串可以這樣判斷：

bool IsEmptyStr(const char* str) {    return !(str && str[0] != '\0');}

但是Go語言中標準的錯誤返回方式不是returnsError這樣。
下面是改進的returnsError：

func returnsError() error {    var p *MyError = nil    if bad() {        return nil    }    return p // Will always return a non-nil error.}

因此，在處理錯誤傳回值的時候，一定要將正常的錯誤值轉換為 nil。

比如，syscall中就有一個bug是由於沒有處理好error導致的：

// syscall: (*Proc).Call always returns non-nil err// http://code.google.com/p/go/issues/detail?id=4686package mainimport "syscall"func main() {    h := syscall.MustLoadDLL("kernel32.dll")    proc := h.MustFindProc("GetVersion")    r, _, err := proc.Call()    major := byte(r)    minor := uint8(r >> 8)    build := uint16(r >> 16)    print("windows version ", major, ".", minor, " (Build ", build, ")\n")   if err != nil {       e := err.(syscall.Errno)       println(err.Error(), "errno =", e)   }}

目前issues4686這個bug已經在修複中。

作為使用者，臨時可以用前面的方法迴避這個bug：

// Issue 4686: syscall: (*Proc).Call always returns non-nil err// https://code.google.com/p/go/issues/detail?id=4686func call(h *syscall.LazyDLL, name string,    a ...uintptr) (r1, r2 uintptr, err error) {    r1, r2, err = h.NewProc(name).Call(a...)    if err.(syscall.Errno) == 0 {        return r1, r2, nil    }    return}

Go作為一個強型別語言，不同類型之前必須要顯示的轉換（而且必須是基礎類型相同）。
這樣可以迴避很多類似C語言中因為隱式類型轉換引入的bug。

但是，Go中interface是一個例外：type到interface和interface之間可能是隱式轉換的。
或許，這是Go做得不太好的地方吧。