08 Go错误与异常：error、panic、recover

对错误和异常处理的支持是现代编程语言的标配，在Go语言中，程序的错误由内建的error接口支持，errors标准包提供了最基本的错误处理方法，用户还可自定义错误处理。而程序的异常处理通常由panic和recover实现触发和终止。

如果你接触过类似JAVA、python等语言，你一定了解try…catch…结构，但是Go中是没有try…catch…的，相反你会看到程序中充斥着大量的if err != nil { …}这样的结构，这种错误处理方式和Go的设计理念有关，在此之前我们先明确什么是错误？很么是异常？

• 什么是错误？

错误是程序中可能出现的问题，比如连接数据库失败，连接网络失败等，在程序设计中，错误处理是业务的一部分。

//go的错误处理接口
type error interface {
	Error() string
}

//errors标准包定义了一个错误处理的实现
// Package errors implements functions to manipulate errors.
package errors

// New returns an error that formats as the given text.
func New(text string) error {
	return &errorString{text}
}

// errorString is a trivial implementation of error.
type errorString struct {
	s string
}

func (e *errorString) Error() string {
	return e.s
}

• 什么是异常？

异常是指在不该出现问题的地方出现问题，是预料之外的，比如空指针引用，下标越界，向空map添加键值等。

    //1.空指针取值
	var aPtr *int //指针声明本身为空，取不了值
	fmt.Println(*aPtr)

	//2.下标越界
	var mm = []int{1, 2, 334, 345, 3}
	fmt.Println(mm[6])

	//3.向空map添加键值对
    var amap map[string]int //只声明没初始化的map没有分配堆内存
	amap["aaa"] = 111

//手工触发异常
func triggerPanic(){
    panic("这是一个手工触发的恐慌！")
}
	
//调用处终止异常转为错误处理
func main(){
    //处理此函数中调用其他函数时产生的恐慌
	defer func() {
		if err := recover(); err != nil {
			fmt.Println("捕捉一个恐慌，恐慌信息为：", err)
			
			...
			
			fmt.Println("这里还能继续运行！！！！")
		}

	}()
	
	//调用一个会触发恐慌的函数
	triggerPanic()
	
}
	

理解了错误和异常的真正含义，我们就能理解Go的错误和异常处理的设计意图。传统的try…catch…结构，很容易让开发人员把错误和异常混为一谈，甚至把业务错误处理的一部分当做异常来处理，于是你会在程序中看到一大堆的catch…。

Go开发团队认为错误应该明确地当成业务的一部分，任何可以预见的问题都需要做错误处理，于是在Go代码中，任何调用者在接收函数返回值的同时也需要对错误进行处理，以防遗漏任何运行时可能的错误。

异常则是意料之外的，甚至你认为在编码中不可能发生的，Go遇到异常会自动触发panic（恐慌），看这意思就知道，程序的异常是非常严重的，触发panic程序会自动退出。除了程序自动触发异常，一些你认为不可允许的情况你也可以手动触发异常，异常应在开发中尽早的发现。

然而在Go中除了触发异常，还可以终止异常并可选的对异常进行错误处理，也就是说，错误和异常是可以相互转换的。

• 错误转异常：

当你在接收到错误信息，业务场景中认为该错误会影响下一流程时，可选择手动触发panic()，异常退出。

• 异常转错误：

在程序的调用处，也可以在最根部的main()函数体内，在此调用recover()接收任何被触发的异常，如何这些异常可以出来，可以选择转成错误处理防止程序退出。

1.当错误原因只有一个时，不返回错误，直接返回一个布尔值。

//如一些判断类的函数IsXXX(),建议返回布尔值
func IsValid(hostName string) bool {
    return hostName == "www.golang.org"
}

2.程序处理中不存在失败情况时，不返回任何错误。

//如某些设置状态变量，结构体属性
var status int
func SetStatus(i int){
    status = i
}

3.当错误原因存在多个且有多个返回值时，error返回参数总在最后一个。

//官方示例
package net/http
func Get(url string) (resp *Response, err error) {
	return DefaultClient.Get(url)
}

//调用处
resp, err := http.Get(url)
if err != nil {
    return nill, err
}

4.一个工程化的项目，其错误原因应该统一定义。

//1.最简单的方式：使用标准error包预定义错误类型
var ERR_NOT_FOUND = errors.New("[error]:File is Not Fount!")
//定义其他类型...

//2.实现error接口，自定义错误类型

//自定义错误结构体
type MyError1 struct {
	Code    int
	Msg string
}

func (me *MyError1) Error() string {
	info := fmt.Sprintf("[MyError1]:Code:%d Mes:%s",me.Code,me.Msg)
	return info
}

//自定义错误的工厂方法
func NewMyError1(code int,msg string) *MyError1 {
	err := new(MyError1)
	err.Code = code
	err.Msg = string
	return err
}

//定义其他错误类型...

5.一个健壮的程序中，调用者尽可能不要忽略返回的错误。

//除非你很有信息这错误不会影响下面的流程，否则还是建议处理err的好，要谨记一切网络都不可信！
resp, _ := http.Get(url)


//类似以上的要少做，一般函数设计中有返回error的，检查做错误处理都是必要的！

6.defer处理要在错误处理之后

//谨记先处理err，否则退出程序
resp, err := http.Get(url)
if err != nil {
    return nill, err
}
defer resp.Body.Close()

7.错误在调用栈中传递时，每层调用栈都务必日志记录，以备溯源。 在开发过程中，最快的debug方式就是打印日志，在错误处理的时候输出日志，一旦程序报错，通过日志溯源一般都能很快定位，与其在debug时打断点，日志溯源效率会高很多

8.有些失败是偶然性的，如网络错误，可以尝试一定次数后再返回失败。这种错误处理在网络IO的开发中非常常见。

9.如果业务上调用者不关心错误，也可以不必返回错误。与其说是不关心，倒不如说关心也处理不了，比如一些资源清理类的操作，如内部出错一般都打印日志即可。

10.出错时，不要轻易忽略除错误外的其他返回值。一般开发中我们会习惯性的在出错时把除错误外的其他返回值置为零值，如果某些计算结果外部调用者需要，则不可忽略。比如，当读取文件发生错误时，Read函数会返回可以读取的字节数以及错误信息。对于这种情况，应该将读取到的字符串和错误信息一起打印出来。

1.开发阶段，坚持速错；

开发阶段尽早发现错误，这是常识。

2.部署阶段，终止异常做必要的错误处理

//某些业务场景中会触发panic，但在线上环境千万不要暴露丑陋的panic，应尽量展示用户友好的信息提示

func funcA() (err error) {
    //A在调用B时使用defer延迟接收panic，并把它转为错误处理
    defer func() {
        if p := recover(); p != nil {
            fmt.Println("panic recover! p:", p)
            str, ok := p.(string)
            if ok {
                err = errors.New(str)
            } else {
                err = errors.New("panic")
            }
            //打印输出一些用户友好的信息
            debug.PrintStack()
        }
    }()
    return funcB()
}

func funcB() error {
    // B的业务处理流程中有一些不可处理的分支，手工触发panic
    panic("foo")
}

3.不应该出现的情况，手动触发异常

switch s := suit(drawCard()); s {
    case "Spades":
    // ...
    case "Hearts":
    // ...
    case "Diamonds":
    // ... 
    case "Clubs":
    // ...
    default:
        panic(fmt.Sprintf("invalid suit %v", s))
}