先看C語(yǔ)言中的類似問(wèn)題：空字符串。
const char* empty_str0 = "";
const char* empty_str1 = "\0empty";
const char* empty_str2 = NULL;```
以上3個(gè)字符串并不相等隅津，但是從某種角度看税朴，它們都是對(duì)應(yīng)空的字符串违施。
empty_str0 指向一個(gè)空的字符串首量，但是empty_str0本身的值是有效的宰译。
empty_str1 指向一個(gè)非空的字符串琐谤，但是字符串的第一個(gè)字符是'\0'蟆技。
empty_str2 本身是一個(gè)空的指針。
Go的error是一個(gè)interface類型斗忌，error的nil問(wèn)題和C語(yǔ)言的字符串類似付魔。
參考官方的error文檔說(shuō)明：
http://golang.org/doc/go_faq.html#nil_error
在底層，interface作為兩個(gè)成員實(shí)現(xiàn)：一個(gè)類型和一個(gè)值飞蹂。該值被稱為接口的動(dòng)態(tài)值几苍， 它是一個(gè)任意的具體值，而該接口的類型則為該值的類型陈哑。對(duì)于 int 值3妻坝， 一個(gè)接口值示意性地包含(int, 3)。
只有在內(nèi)部值和類型都未設(shè)置時(shí)(nil, nil)惊窖，一個(gè)接口的值才為 nil刽宪。特別是，一個(gè) nil 接口將總是擁有一個(gè) nil 類型界酒。若我們?cè)谝粋€(gè)接口值中存儲(chǔ)一個(gè) int 類型的指針圣拄，則內(nèi)部類型將為 int，無(wú)論該指針的值是什么：(*int, nil)毁欣。 因此庇谆，這樣的接口值會(huì)是非 nil 的，即使在該指針的內(nèi)部為 nil凭疮。
下面是一個(gè)錯(cuò)誤的錯(cuò)誤返回方式：
func returnsError() error {
var p *MyError = nil
if bad() {
p = ErrBad
}
return p // Will always return a non-nil error.
}```
這里 p 返回的是一個(gè)有效值（非nil）饭耳，值為 nil。 類似上面的 empty_str0执解。
因此寞肖，下面判斷錯(cuò)誤的代碼會(huì)有問(wèn)題：
func main() {
if err := returnsError(); err != nil {
panic(nil)
}
}```
針對(duì) returnsError 的問(wèn)題，可以這樣處理（不建議的方式）：
func main() {
if err := returnsError(); err.(MyError) != nil {
panic(nil)
}
}```
在判斷前先將err轉(zhuǎn)型為MyError衰腌，然后再判斷err的值新蟆。 類似的C語(yǔ)言空字符串可以這樣判斷：
bool IsEmptyStr(const char* str) {
return !(str && str[0] != '\0');
}```
但是Go語(yǔ)言中標(biāo)準(zhǔn)的錯(cuò)誤返回方式不是returnsError這樣。 下面是改進(jìn)的returnsError：
func returnsError() error {
if bad() {
return (*MyError)(err)
}
return nil
}```
因此右蕊，在處理錯(cuò)誤返回值的時(shí)候琼稻，一定要將正常的錯(cuò)誤值轉(zhuǎn)換為 nil。
比如尤泽，syscall中就有一個(gè)bug是由于沒有處理好error導(dǎo)致的：
// syscall: (*Proc).Call always returns non-nil err
// http://code.google.com/p/go/issues/detail?id=4686
package main
import "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這個(gè)bug已經(jīng)在修復(fù)中欣簇。
作為用戶，臨時(shí)可以用前面的方法回避這個(gè)bug：
// Issue 4686: syscall: (*Proc).Call always returns non-nil err
// https://code.google.com/p/go/issues/detail?id=4686
func 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作為一個(gè)強(qiáng)類型語(yǔ)言坯约，不同類型之前必須要顯示的轉(zhuǎn)換（而且必須是基礎(chǔ)類型相同）熊咽。 這樣可以回避很多類似C語(yǔ)言中因?yàn)殡[式類型轉(zhuǎn)換引入的bug。
但是闹丐，Go中interface是一個(gè)例外：type到interface和interface之間可能是隱式轉(zhuǎn)換的横殴。 或許，這是Go做得不太好的地方吧卿拴。
原文鏈接：https://my.oschina.net/chai2010/blog/117923
