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攻城獅 的文章
