如何解決編寫代碼時出現的Go問題

這篇文章主要介紹“如何解決編寫代碼時出現的Go問題”，在日常操作中，相信很多人在如何解決編寫代碼時出現的Go問題問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何解決編寫代碼時出現的Go問題”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

案例一

代碼示例如下：

type MyErr struct {     Msg string }  func main() {     var e error     e = GetErr()     log.Println(e == nil) }  func GetErr() *MyErr {     return nil }  func (m *MyErr) Error() string {     return "腦子進煎魚了" }

請思考一下，這段程序的輸出結果是什么?

該程序所調用的 GetErr 方法所返回的是 nil，而外部判斷是 e == nil，因此最終的輸出結果是 true，對嗎?

輸出結果如下：

2021/04/04 08:39:04 false

答案是：false。

案例二

代碼示例如下：

type Base interface {     do() }  type App struct { }  func main() {     var base Base     base = GetApp()          log.Println(base)     log.Println(base == nil) }  func GetApp() *App {     return nil } func (a *App) do() {}

請思考一下，這段程序的輸出結果是什么?

該程序調用了 GetApp 方法，該方法返回的是 nil，因此其賦值的 base 也是 nil。因此判斷 base == nil 的最終輸出結果是和 true，對嗎?

輸出結果如下：

2021/04/04 08:59:00 <nil> 2021/04/04 08:59:00 false

答案是：和 false。

為什么

為什么，這兩段 Go 程序是怎么回事...也太反直覺了?其背后的原因本質上還是對 Go 語言中 interface 的基本原理的理解。

在案例一中，雖然 GetErr 方法確實是返回了 nil，返回的類型也是具體的 *MyErr 類型。但是其接收的變量卻不是具體的結構類型，而是 error  類型：

var e error e = GetErr()

在 Go 語言中， error 類型本質上是 interface：

type error interface {     Error() string }

因此兜兜轉轉又回到了 interface 類型的問題，interface 不是單純的值，而是分為類型和值。

所以傳統認知的此 nil 并非彼 nil，必須得類型和值同時都為 nil 的情況下，interface 的 nil 判斷才會為 true。

在案例一中，結合代碼邏輯，更符合場景的是：

var e *MyErr e = GetErr() log.Println(e == nil)

輸出結果就會是 true。

在案例二中，也是一樣的結果，原因也是 interface。不管是 error  接口(interface)，還是自定義的接口，背后原理一致，自然也就結果一致了。

到此，關于“如何解決編寫代碼時出現的Go問題”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！