先来狠狠吐个槽
要吐槽 Go1 的 error ,那咱得先整明白大家为啥都猛喷它的错误处理做得不咋地。在 Go 语言里头,error 本质上其实就是个 Error 的接口:
type error interface {
Error() string
}
实际的应用场景如下:
func main() {
x, err := foo()
if err != nil {
// handle error
}
}
单瞅这个例子,感觉好像没啥大毛病,可要是工程规模一变大,那可就不得了啦!
很明显,if err!= nil 这种逻辑在工程代码里那是扎堆出现,Go 代码里的 if err!= nil 甚至能占到工程代码量的 30% 还多呢:
func main() {
r1, err := fun1()
if err != nil {
// handle error
}
r2, err := fun2()
if err != nil {
// handle error
}
r3, err := fun3()
if err != nil {
// handle error
}
r4, err := fun4()
if err != nil {
// handle error
}
}
猛这么一对比,4行函数调用,12行错误处理,这可真是让人头大呀!
另外呀,既然是错误处理,那肯定不只是简简单单地return err
这么回事儿。在工程实践中,项目代码那都是层层嵌套的,如果直接写成:
if err != nil {
return err
}
在实际工程里,这可绝对不行。您说您咋能知道具体是哪儿抛出的错误信息呀,实际出错的时候那只能是瞎蒙乱猜。所以就得加上各种描述信息:
if err != nil {
return fmt.Errorf("xxx, error: %s", err.Error())
}
try 函数
在 golang 的提案里,介绍了一种新的内置函数“try”,这小家伙的出现是为了简化 Go 程序里那让人头疼的错误处理流程,同时还能保住语言的简洁明快和直截了当。try
提供了一种神奇的机制,能让常见的错误检查模式表达得更简洁明了,把那些烦人的样板代码都给减少了,让代码的可读性和可维护性都蹭蹭往上涨。
虽说当前 Go 语言通过返回错误作为结果来处理错误的方式简单又灵活,但是在实际操作中,大量的错误检查代码常常让代码变得又长又复杂,就像一团乱麻,让人很难快速搞懂其中的逻辑流程。特别是在函数链里有好几个可能返回错误的步骤时,错误传播和处理的代码能占程序的一大部分,简直是“鸠占鹊巢”。
try 表达式
引入了一个新的内置函数try
,它接收一个可能返回错误的表达式当参数,要是这个表达式执行成功(也就是没返回错误),那就返回表达式的值。要是表达式返回了一个错误,那try
会立马“翻脸”,终止当前函数的执行,把错误毫不留情地返回给调用者。它的语法是这样的:
result := try expression
x1, x2, … xn = try(f())
等同于下面的代码
t1, … tn, te := f() // t1, … tn, te are local (invisible) temporaries
if te != nil {
err = te // assign te to the error result parameter
return // return from enclosing function
}
x1, … xn = t1, … tn // assignment only if there was no error
demo
来瞧瞧下面这个例子,展示了咋用try
来简化文件读取操作的错误处理:
func ReadData(filename string) ([]byte, error) {
f, err := os.Open(filename)
if err != nil {
return nil, err
}
defer f.Close()
data, err := ioutil.ReadAll(f)
if err != nil {
return nil, err
}
return data, nil
}
用try
可以简化成这样:
func ReadData(filename string) ([]byte, error) {
f := try os.Open(filename)
defer f.Close()
data := try ioutil.ReadAll(f)
return data, nil
}
总结
- 错误传播:
try
直接就让包含它的函数“缴械投降”,然后返回错误,这就意味着它不能用在错误发生后还想“垂死挣扎”继续执行的场景里。 - 控制流影响:因为
try
导致的提前“打退堂鼓”,开发者得瞪大眼睛留神它对局部变量的生命周期和资源管理的影响。 - 简洁与清晰:虽说
try
减少了错误检查的显式代码,可要是过度使用,可能会影响代码的可读性,特别是在复杂得像迷宫一样的逻辑里。
try
这个内置函数是对 Go 错误处理模型的一个补充,目标就是提供一种更简练的错误处理方式,同时保持语言的其他核心特性不变。
资料
- https://github.com/golang/go/issues/32437
- https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md