Go语言中优雅的处理错误，而不仅仅只是检查( 三 ) _Go语言

文章插图

我们使用这个函数写一个读取配置文件的函数，然后在 main 中调用。

文章插图

如果 ReadConfig 发生错误，由于使用了 errors.Wrap，我们可以得到一个 K&D 风格的包含相关信息的错误
could not read config: open failed: open /Users/dfc/.settings.xml: no such file or directory因为 errors.Wrap 生成了发生错误时的调用栈信息，所以我们可以查看额外的调用栈调试信息。这又是一个同样的例子，但是这次我们用 errors.Print 替换 fmt.Println

文章插图

我们会得到如下的信息：

文章插图

第一行来至 ReadConfig，第二行来至 os.Open 的 ReadFile，剩下的来至 os 包，没有携带位置信息。
现在我们介绍了关于打包错误生成栈的概念，我们需要谈谈如何解包。下面是 errors.Cause 函数的作用。

文章插图

操作中，当你需要检查一个错误是否匹配一个指定值或类型时，你需要先使用 errors.Cause 获取原始错误信息
只处理一次错误最后我想要说的是，你只需要处理一次错误。处理错误意味着检查错误值，然后作出决定。

文章插图

如果你不需要做出决定，你可以忽略这个错误。在上面的例子可以看到我们忽略了 w.Write 返回的错误。
但是在返回一个错误时做出多个决定也是有问题的。

文章插图

在这个例子中，如果 Write 发生错误，一行信息会写入日志，记录发送错误的文件和行号，同时把错误返回给调用者，同样的调用者也可能会写入日志，然后返回，直到程序的最顶层。
日志文件里就会出现一堆重复的信息，但是在程序最顶层获得的原始错误却没有任何相关信息。

文章插图

使用 errors 包可以让你在 error 里面加入相关信息，并且内容是可以被人和机器所识别的。
结论最后，错误是你提供的包中公开 API 的一部分，要像其他公开 API 一样小心对待。
为了获得最大的灵活性，我建议你尝试把所有的错误当做封装错误来处理，在那些无法做到的情况下，断言行为错误，而不是类型或值。
【Go语言中优雅的处理错误，而不仅仅只是检查】尽可能少的在你程序中使用标记错误，在错误发生时尽早的使用 errors.Wrap 打包封装为封装错误。