人非圣贤，孰能无过，有则改之，无则加勉。在编程语言层面，错误处理方式大体上有两大流派，分别是以 Python 为代表的异常捕获机制(try....catch)；以及以 Go lang 为代表的错误返回机制(return error)，前者是自动化流程，模式化的语法隔离正常逻辑和错误逻辑，而后者，需要将错误处理判断编排在正常逻辑中。虽然模式化语法更容易让人理解，但从系统资源开销角度看，错误返回机制明显更具优势。
返回错误
Go lang 的错误(error)也是一种数据类型，错误用内置的 error 类型表示，就像其他的数据类型的，比如字符串、整形之类，错误的具体值可以存储在变量中，从函数中返回：
package main import "fmt" func handle() (int, error) { return 1, nil } func main() { i, err := handle() if err != nil { fmt.Println("报错了") return } fmt.Println("逻辑正常") fmt.Println(i) }
复制代码
程序返回：
这里的逻辑是，如果 handle 函数成功执行并且返回，那么入口函数就会正常打印返回值 i，假设 handel 函数执行过程中出现错误，将返回一个非 nil 错误。
如果一个函数返回一个错误，那么理论上，它肯定是函数返回的最后一个值，因为在执行阶段中可能会返回正常的值，而错误位置是未知的，所以，handle 函数返回的值是最后一个值。
go lang 中处理错误的常见方式是将返回的错误与 nil 进行比较。nil 值表示没有发生错误，而非 nil 值表示出现错误。在我们的例子中，我们检查错误是否为 nil。如果它不是 nil，我们会通过 fmt.Println 方法提醒用户并且从主函数返回，结束逻辑。
再来个例子：
package main import ( "fmt" "net/http" ) func main() { resp, err := http.Get("123123") if err != nil { fmt.Println(err) return } fmt.Println(resp.StatusCode) }
复制代码
这回我们使用标准库包 http 向一个叫做 123123 的网址发起请求，当然了，请求过程中有可能发生一些未知错误，所以我们使用 err 变量获取 Get 方法的最后一个返回值，如果 err 不是 nil，那么就说明请求过程中报错了，这里打印具体错误，然后从主函数中返回。
程序返回：
Get "123123": unsupported protocol scheme ""
复制代码
很明显，肯定报错了，因为 Go lang 并不知道所谓的 123123 到底是什么网络协议。
具体错误类型
在 Go lang 中，错误本质上是一个接口：
type error interface { Error() string }
复制代码
包含一个带有 Error 字符串的函数。任何实现这个接口的类型都可以作为一个错误使用。这个函数可以打印出具体错误的说明。
当打印错误时，fmt.Println 函数在内部调用 Error() 方法来获取错误的说明：
Get "123123": unsupported protocol scheme ""
复制代码
但有的时候，除了系统级别的错误说明，我们还需要针对错误进行分类，通过不同的错误类型的种类来决定下游的处理方式。
既然有了错误说明，为什么还需要错误类型，直接通过说明判断不就行了？这是因为系统的错误说明可能会随着 go lang 版本的迭代而略有不同，而一个错误的错误类型则大概率不会发生变化。
通过对标准库文档的解读：https://pkg.go.dev/net/http#ProtocolError，我们就可以对返回的错误类型进行判断：
package main import ( "fmt" "net" "net/http" ) func main() { resp, err := http.Get("123123") if err, ok := err.(net.Error); ok && err.Timeout() { fmt.Println("超时错误") fmt.Println(err) } else if err != nil { fmt.Println("其他错误") fmt.Println(err) } fmt.Println(resp.StatusCode) }
复制代码
程序返回：
其他错误 Get "123123": unsupported protocol scheme ""
复制代码
这里我们把超时(Timeout)和其他错误区分开来，分别进入不同的错误处理逻辑。
定制错误
定制错误通过标准库 errors 为程序的错误做个性化定制，假设某个函数的作用是做除法运算，而如果除数为 0，则返回一个错误：
package main import ( "errors" "fmt" ) func test(num1 int, num2 int) (int, error) { if num2 == 0 { return 0, errors.New("除数不能为0") } return num1 / num2, nil } func main() { res, err := test(2, 1) if err != nil { fmt.Println(err) return } fmt.Println("结果是", res) }
复制代码
程序返回：
但如果参数不合法：
package main import ( "errors" "fmt" ) func test(num1 int, num2 int) (int, error) { if num2 == 0 { return 0, errors.New("除数不能为0") } return num1 / num2, nil } func main() { res, err := test(2, 0) if err != nil { fmt.Println(err) return } fmt.Println("结果是", res) }
复制代码
程序返回：
假设，出于某种原因，我们对除数有定制化需求，比如不能为 0 或者为 1，但条件变成了多条件，此时需要将除数显性的展示在错误说明中，以便更具象化的提醒用户：
package main import ( "fmt" ) func test(num1 int, num2 int) (int, error) { if (num2 == 0) || (num2 == 1) { return 0, fmt.Errorf("除数为%d,除数不能为0或者1", num2) } return num1 / num2, nil } func main() { res, err := test(2, 1) if err != nil { fmt.Println(err) return } fmt.Println("结果是", res) }
复制代码
程序返回：
这里使用 fmt 包的 Errorf 函数根据一个格式说明器格式化错误，并返回一个字符串作为值来满足错误。
此外，还可以使用使用结构体和结构体中的属性提供关于错误的更多信息：
type testError struct { err string num int }
复制代码
这里定义结构体 testError，里面两个属性，分别是错误说明和除数值。
随后，我们使用一个指针接收器区域错误来实现错误接口的 Error() string 方法。这个方法打印出错误的除数值和错误说明：
func (e *testError) Error() string { return fmt.Sprintf("除数 %d:%s", e.num, e.err) }
复制代码
接着通过结构体寻址调用：
func test(num1 int, num2 int) (int, error) { if (num2 == 0) || (num2 == 1) { return 0, &testError{"除数非法", num2} } return num1 / num2, nil }
复制代码
完整代码：
package main import ( "fmt" ) type testError struct { err string num int } func (e *testError) Error() string { return fmt.Sprintf("除数 %d:%s", e.num, e.err) } func test(num1 int, num2 int) (int, error) { if (num2 == 0) || (num2 == 1) { return 0, &testError{"除数非法", num2} } return num1 / num2, nil } func main() { res, err := test(2, 1) if err != nil { fmt.Println(err) return } fmt.Println("结果是", res) }
复制代码
程序返回：
通过结构体的定义，错误说明更加规整，并且更易于维护。
异常（panic/recover）
异常的概念是，本来不应该出现问题的地方出现了问题，某些情况下，当程序发生异常时，无法继续运行，此时，我们会使用 panic 来终止程序。当函数发生 panic 时，它会终止运行，在执行完所有的延迟函数后，程序返回到该函数的调用方，这样的过程会一直持续下去，直到当前协程的所有函数都返回退出，然后程序会打印出 panic 信息，接着打印出堆栈跟踪，最后程序终止：
package main import "fmt" func main() { panic("panic error") fmt.Println("下游逻辑") }
复制代码
程序返回：
可以看到，panic 方法执行后，程序下游逻辑并未执行，所以 panic 使用场景是，当下游依赖上游的操作，而上游的问题导致下游无计可施的时候，使用 panic 抛出异常。
但延迟执行是个例外：
package main import "fmt" func myTest() { defer fmt.Println("defer myTest") panic("panic myTest") } func main() { defer fmt.Println("defer main") myTest() }
复制代码
程序返回：
defer myTest defer main panic: panic myTest
复制代码
这里当函数发生 panic 时，它会终止运行，在执行完所有的延迟函数后，程序返回到该函数的调用方，这样的过程会一直持续下去，直到当前协程的所有函数都返回退出，然后程序会打印出 panic 信息，接着打印出堆栈跟踪，最后程序终止。
此外，recover 方法可以捕获异常的异常，从而打印异常信息后，继续执行下游逻辑：
package main import "fmt" func outOfArray(x int) { defer func() { // recover() 可以将捕获到的 panic 信息打印 if err := recover(); err != nil { fmt.Println(err) } }() var array [5]int array[x] = 1 } func main() { outOfArray(20) fmt.Println("下游逻辑") }
复制代码
程序返回：
runtime error: index out of range [20] with length 5 下游逻辑
复制代码
结语
综上，Go lang 的错误处理，属实不太优雅，大多数情况下会有很多重复代码：if err != nil，这在一定程度上影响了代码的可读性和可维护性，同时容易丢失底层错误类型，且定位错误时，很难得到错误链，也就是在一定程度上阻碍了错误的追根溯源，但反过来想，错误本来就是业务的一部分，从业务角度上看，Golang 这种返回错误的方式更贴合业务逻辑，你可以用多返回值包含 error 处理业务异常，用 recover 处理系统异常。业务异常，可以定义为不会引起系统崩溃下游瘫痪的异常；系统异常可以定义为会引起系统崩溃下游瘫痪的异常。所以，归根结底，一套功夫的威力，真的不在于其招式的设计，而在于运用功夫的那个人能否发挥这套武功的全部潜力。
评论