聊聊Golang饱受争议的Error( 二 ) _Golang

如果ReadConfig()执行失败，就会得到下面这一行十分美观的报错：
could not read config: open failed: open /Users/dfc/.settings.xml: no such file or directory而如果用fmt.Printf和%+v格式来输出就能看到更清晰、更有层次的错误堆栈：
func main() {_, err := ReadConfig()if err != nil {fmt.Printf("%+v",err)os.Exit(1)}}

文章插图
图片
然后我们再来看Cause的使用。

type temporary interface{Temporary() bool}// IsTemporary returns true if err is temporary.func IsTemporary(err error) bool {te, ok := errors.Cause(err).(temporary)return ok && te.Temporary()}

当需要检查一个错误与一个特定的值或类型时。比如此处，先用Cause取出错误，做断言，最后调用Temporary()，如果断言失败，ok就会是false ，就不会调用右边的Temporary()去执行。
如果 && 运算符左侧的子表达式为 false，则不会检查右侧的表达式。因为只要有一个子表达式为 false，则整个表达式都为 false，所以再检查剩余的表达式会浪费 CPU 时间。这被称为短路评估。
本文转载自微信公众号「程序员升级打怪之旅」

【聊聊Golang饱受争议的Error】