Go 語言的異常處理語法絕對是獨樹一幟，在我見過的諸多高級語言中，Go 語言的錯誤處理形式就是一朵奇葩。一方面它鼓勵你使用 C 語言的形式將錯誤通過返回值來進行傳遞，另一方面它還提供了高級語言一般都有的異常拋出和捕獲的形式，但是又不鼓勵你使用這個形式。後面我們統一將返回值形式的稱為「錯誤」，將拋出捕獲形式的稱為「異常」。
Go 語言的錯誤處理在業界飽受批評，不過既然我們已經入了這個坑，那還是好好蹲著吧。
錯誤接口
Go 語言規定凡是實現了錯誤接口的對象都是錯誤對象，這個錯誤接口只定義了一個方法。
<code>type error interface {
Error() string
}
複製代碼/<code>注意這個接口的名稱，它是小寫的，是內置的全局接口。通常一個名字如果是小寫字母開頭，那麼它在包外就是不可見的，不過 error 是內置的特殊名稱，它是全局可見的。
編寫一個錯誤對象很簡單，寫一個結構體，然後掛在 Error() 方法就可以了。
<code>package main
import "fmt"
type SomeError struct {
\tReason string
}
func (s SomeError) Error() string {
\treturn s.Reason
}
func main() {
\tvar err error = SomeError{"something happened"}
\tfmt.Println(err)
}
---------------
something happened
複製代碼/<code>
對於上面代碼中錯誤對象的形式非常常用，所以 Go 語言內置了一個通用錯誤類型，在 errors 包裡。這個包還提供了一個 New() 函數讓我們方便地創建一個通用錯誤。
<code>package errors
func New(text string) error {
\treturn &errorString{text}
}
type errorString struct {
\ts string
}
func (e *errorString) Error() string {
\treturn e.s
}
複製代碼/<code>
注意這個結構體 errorString 是首字母小寫的，意味著我們無法直接使用這個類型的名字來構造錯誤對象，而必須使用 New() 函數。
<code>var err = errors.New("something happened")
複製代碼/<code>如果你的錯誤字符串需要定製一些參數，可使用 fmt 包提供了 Errorf 函數
<code>var thing = "something"
var err = fmt.Errorf("%s happened", thing)
複製代碼/<code>
錯誤處理首體驗
在 Java 語言裡，如果遇到 IO 問題通常會拋出 IOException 類型的異常，在 Go 語言裡面它不會拋異常，而是以返回值的形式來通知上層邏輯來處理錯誤。下面我們通過讀文件來嘗試一下 Go 語言的錯誤處理，讀文件需要使用內置的 os 包。
<code>package main
import "os"
import "fmt"
func main() {
\t// 打開文件
\tvar f, err = os.Open("main.go")
\tif err != nil {
\t\t// 文件不存在、權限等原因
\t\tfmt.Println("open file failed reason:" + err.Error())
\t\treturn
\t}
\t// 推遲到函數尾部調用，確保文件會關閉
\tdefer f.Close()
\t// 存儲文件內容
\tvar content = []byte{}
\t// 臨時的緩衝，按塊讀取，一次最多讀取 100 字節
\tvar buf = make([]byte, 100)
\tfor {
\t\t// 讀文件，將讀到的內容填充到緩衝
\t\tn, err := f.Read(buf)
\t\tif n > 0 {
\t\t\t// 將讀到的內容聚合起來
\t\t\tcontent = append(content, buf[:n]...)
\t\t}
\t\tif err != nil {
\t\t\t// 遇到流結束或者其它錯誤
\t\t\tbreak
\t\t}
\t}
\t// 輸出文件內容
\tfmt.Println(string(content))
}
-------
package main
import "os"
import "fmt"
.....
複製代碼/<code>
在這段代碼裡有幾個點需要特別注意。第一個需要注意的是 os.Open()、f.Read() 函數返回了兩個值，Go 語言不但允許函數返回兩個值，三個值四個值都是可以的，只不過 Go 語言普遍沒有使用多返回值的習慣，僅僅是在需要返回錯誤的時候才會需要兩個返回值。除了錯誤之外，還有一個地方需要兩個返回值，那就是字典，通過第二個返回值來告知讀取的結果是零值還是根本就不存在。
<code>var score, ok := scores["apple"]
複製代碼/<code>
第二個需要注意的是 defer 關鍵字，它將文件的關閉調用推遲到當前函數的尾部執行，即使後面的代碼拋出了異常，文件關閉也會確保被執行，相當於 Java 語言的 finally 語句塊。defer 是 Go 語言非常重要的特性，在日常應用開發中，我們會經常使用到它。
第三個需要注意的地方是 append 函數參數中出現了 ... 符號。在切片章節，我們知道 append 函數可以將單個元素追加到切片中，其實 append 函數可以一次性追加多個元素，它的參數數量是可變的。
<code>var s = []int{1,2,3,4,5}
s = append(s,6,7,8,9)
複製代碼/<code>但是讀文件的代碼中需要將整個切片的內容追加到另一個切片中，這時候就需要 ... 操作符，它的作用是將切片參數的所有元素展開後傳遞給 append 函數。你可能會擔心如果切片裡有成百上千的元素，展開成元素再傳遞會不會非常耗費性能。這個不必擔心，展開只是形式上的展開，在實現上其實並沒有展開，傳遞過去的參數本質上還是切片。
第四個需要注意的地方是讀文件操作 f.Read() ，它會將文件的內容往切片裡填充，填充的量不會超過切片的長度(注意不是容量)。如果將緩衝改成下面這種形式，就會死循環！
<code>var buf = make([]byte, 0, 100)
複製代碼/<code>
另外如果遇到文件尾了，切片就不會填滿。所以需要通過返回值 n 來明確到底讀了多少字節。
體驗 Redis 的錯誤處理
上面讀文件的例子並沒有讓讀者感受到錯誤處理的不爽，下面我們要引入 Go 語言 Redis 的客戶端包，來真實體驗一下 Go 語言的錯誤處理有多讓人不快。
使用第三方包，需要使用 go get 指令下載這個包，該指令會將第三方包放到 GOPATH 目錄下。
<code>go get github.com/go-redis/redis
複製代碼/<code>
下面我要實現一個小功能，獲取 Redis 中兩個整數值，然後相乘，再存入 Redis 中
<code>package main
import "fmt"
import "strconv"
import "github.com/go-redis/redis"
func main() {
// 定義客戶端對象，內部包含一個連接池
\tvar client = redis.NewClient(&redis.Options {
\t\tAddr: "localhost:6379",
\t})
\t// 定義三個重要的整數變量值，默認都是零
\tvar val1, val2, val3 int
\t// 獲取第一個值
\tvalstr1, err := client.Get("value1").Result()
\tif err == nil {
\t\tval1, err = strconv.Atoi(valstr1)
\t\tif err != nil {
\t\t\tfmt.Println("value1 not a valid integer")
\t\t\treturn
\t\t}
\t} else if err != redis.Nil {
\t\tfmt.Println("redis access error reason:" + err.Error())
\t\treturn
\t}
\t// 獲取第二個值
\tvalstr2, err := client.Get("value2").Result()
\tif err == nil {
\t\tval2, err = strconv.Atoi(valstr2)
\t\tif err != nil {
\t\t\tfmt.Println("value1 not a valid integer")
\t\t\treturn
\t\t}
\t} else if err != redis.Nil {
\t\tfmt.Println("redis access error reason:" + err.Error())
\t\treturn
\t}
\t// 保存第三個值
\tval3 = val1 * val2
\tok, err := client.Set("value3",val3, 0).Result()
\tif err != nil {
\t\tfmt.Println("set value error reason:" + err.Error())
\t\treturn
\t}
\tfmt.Println(ok)
}
------
OK
複製代碼/<code>
因為 Go 語言中不輕易使用異常語句，所以對於任何可能出錯的地方都需要判斷返回值的錯誤信息。上面代碼中除了訪問 Redis 需要判斷之外，字符串轉整數也需要判斷。
另外還有一個需要特別注意的是因為字符串的零值是空串而不是 nil，你不好從字符串內容本身判斷出 Redis 是否存在這個 key 還是對應 key 的 value 為空串，需要通過返回值的錯誤信息來判斷。代碼中的 redis.Nil 就是客戶端專門為 key 不存在這種情況而定義的錯誤對象。
相比於寫習慣了 Python 和 Java 程序的朋友們來說，這樣繁瑣的錯誤判斷簡直太地獄了。不過還是那句話，習慣了就好。
異常與捕捉
Go 語言提供了 panic 和 recover 全局函數讓我們可以拋出異常、捕獲異常。它類似於其它高級語言裡常見的 throw try catch 語句，但是又很不一樣，比如 panic 函數可以拋出來任意對象。下面我們看一個使用 panic 的例子
<code>package main
import "fmt"
var negErr = fmt.Errorf("non positive number")
func main() {
\tfmt.Println(fact(10))
\tfmt.Println(fact(5))
\tfmt.Println(fact(-5))
\tfmt.Println(fact(15))
}
// 讓階乘函數返回錯誤太不雅觀了
// 使用 panic 會合適一些
func fact(a int) int{
\tif a <= 0 {
\t\tpanic(negErr)
\t}
\tvar r = 1
\tfor i :=1;i<=a;i++ {
\t\tr *= i
\t}
\treturn r
}
-------
3628800
120
panic: non positive number
goroutine 1 [running]:
main.fact(0xfffffffffffffffb, 0x1)
\t/Users/qianwp/go/src/github.com/pyloque/practice/main.go:16 +0x75
main.main()
\t/Users/qianwp/go/src/github.com/pyloque/practice/main.go:10 +0x122
exit status 2
複製代碼/<code>
上面的代碼拋出了 negErr，直接導致了程序崩潰，程序最後打印了異常堆棧信息。下面我們使用 recover 函數來保護它，recover 函數需要結合 defer 語句一起使用，這樣可以確保 recover() 邏輯在程序異常的時候也可以得到調用。
<code>package main
import "fmt"
var negErr = fmt.Errorf("non positive number")
func main() {
\tdefer func() {
\t\tif err := recover(); err != nil {
\t\t\tfmt.Println("error catched"， err)
\t\t}
\t}()
\tfmt.Println(fact(10))
\tfmt.Println(fact(5))
\tfmt.Println(fact(-5))
\tfmt.Println(fact(15))
}
func fact(a int) int{
\tif a <= 0 {
\t\tpanic(negErr)
\t}
\tvar r = 1
\tfor i :=1;i<=a;i++ {
\t\tr *= i
\t}
\treturn r
}
-------
3628800
120
error catched non positive number
複製代碼/<code>
輸出結果中的異常堆棧信息沒有了，說明捕獲成功了，不過即使程序不再崩潰，異常點後面的邏輯也不會再繼續執行了。上面的代碼中需要注意的是我們使用了匿名函數 func() {...}
<code>defer func() {
if err := recover(); err != nil {
fmt.Println("error catched"， err)
}
}()
複製代碼/<code>尾部還有個括號是怎麼回事，為什麼還需要這個括號呢？它表示對匿名函數進行了調用。對比一下前面寫的文件關閉尾部的括號就能理解了
<code>defer f.Close()
複製代碼/<code>
還有個值得注意的地方時，panic 拋出的對象未必是錯誤對象，而 recover() 返回的對象正是 panic 拋出來的對象，所以它也不一定是錯誤對象。
<code>func panic(v interface{})
func recover() interface{}
複製代碼/<code>我們經常還需要對 recover() 返回的結果進行判斷，以挑選出我們願意處理的異常對象類型，對於那些不願意處理的，可以選擇再次拋出來，讓上層來處理。
<code>defer func() {
\tif err := recover(); err != nil {
\t\tif err == negErr {
\t\t\tfmt.Println("error catched", err)
\t\t} else {
\t\t\tpanic(err) // rethrow
\t\t}
\t}
}()
複製代碼/<code>異常的真實應用
Go 語言官方表態不要輕易使用 panic recover，除非你真的無法預料中間可能會發生的錯誤，或者它能非常顯著地簡化你的代碼。簡單一點說除非逼不得已，否則不要使用它。
在一個常見的 Web 應用中，不能因為個別 URL 處理器拋出異常而導致整個程序崩潰，就需要在每個 URL 處理器外面包括一層 recover() 來恢復異常。
在 json 序列化過程中，邏輯上需要遞歸處理 json 內部的各種類型，每一種容器類型內部都可能會遇到不能序列化的類型。如果對每個函數都使用返回錯誤的方式來編寫代碼，會顯得非常繁瑣。所以在內置的 json 包裡也使用了 panic，然後在調用的最外層包裹了 recover 函數來進行恢復，最終統一返回一個 error 類型。
你可以想象一下，內置 json 包的開發者在設計開發這個包的時候應該也是糾結的焦頭爛額，最終還是使用了 panic 和 recover 來讓自己的代碼變的好看一些。
知乎最近發表了內部的 Go 語言實踐方案，因為忍受不了代碼裡太多的錯誤判斷語句，它們的業務異常也改用 panic 拋出來，雖然這並不是官方的推薦模式。
多個 defer 語句
有時候我們需要在一個函數里使用多次 defer 語句。比如拷貝文件，需要同時打開源文件和目標文件，那就需要調用兩次 defer f.Close()。
<code>package main
import "fmt"
import "os"
func main() {
\tfsrc, err := os.Open("source.txt")
\tif err != nil {
\t\tfmt.Println("open source file failed")
\t\treturn
\t}
\tdefer fsrc.Close()
\tfdes, err := os.Open("target.txt")
\tif err != nil {
\t\tfmt.Println("open target file failed")
\t\treturn
\t}
\tdefer fdes.Close()
\tfmt.Println("do something here")
}
複製代碼/<code>
需要注意的是 defer 語句的執行順序和代碼編寫的順序是反過來的，也就是說最先 defer 的語句最後執行，為了驗證這個規則，我們來改寫一下上面的代碼
<code>package main
import "fmt"
import "os"
func main() {
\tfsrc, err := os.Open("source.txt")
\tif err != nil {
\t\tfmt.Println("open source file failed")
\t\treturn
\t}
\tdefer func() {
\t\tfmt.Println("close source file")
\t\tfsrc.Close()
\t}()
\tfdes, err := os.Open("target.txt")
\tif err != nil {
\t\tfmt.Println("open target file failed")
\t\treturn
\t}
\tdefer func() {
\t\tfmt.Println("close target file")
\t\tfdes.Close()
\t}()
\tfmt.Println("do something here")
}
--------
do something here
close target file
close source file
複製代碼/<code>
下一節我們開講 Go 語言最重要的特色功能 —— 通道與協程
閱讀更多 Echa攻城獅 的文章
