一文悟透备受争议的 Go 语言错误处理

参考资料【Go 语言的错误处理机制是一个优秀的设计吗?】是知乎上的一个回答，阐述了 Go 对待错误和异常的不同处理方式，前者使用 error，后者使用 panic，这样的处理比较 Java 那种错误异常一锅端的做法更有优势。

【如何优雅的在Golang中进行错误处理】对于在业务上如何处理 error，给出了一些很好的示例。

尝试破局

这部分的内容主要来自 Dave cheney GoCon 2016 的演讲，参考资料可以直达原文。

经常听到 Go 有很多“箴言”，说得很顺口，但理解起来并不是太容易，因为它们大部分都是有故事的。例如，我们常说：

Don’t communicating by sharing memory, share memory by communicating.

文中还列举了很多，都很有意思：

下面我们讲三条关于 error 的“箴言”。

Errors are just values

Errors are just values 的实际意思是只要实现了 Error 接口的类型都可以认为是 Error，重要的是要理解这些“箴言”背后的道理。

作者把处理 error 的方式分为三种：

• Sentinel errors
• Error Types
• Opaque errors

我们来挨个说。首先 Sentinel errors，Sentinel 来自计算机中常用的词汇，中文意思是“哨兵”。以前在学习快排的时候，会有一个“哨兵”，其他元素都要和“哨兵”进行比较，它划出了一条界限。

这里 Sentinel errors 实际想说的是这里有一个错误，暗示处理流程不能再进行下去了，必须要在这里停下，这也是一条界限。而这些错误，往往是提前约定好的。

例如，io 包里的 io.EOF，表示“文件结束”错误。但是这种方式处理起来，不太灵活：

func main() { 
    r := bytes.NewReader([]byte("0123456789")) 
     
    _, err := r.Read(make([]byte, 10)) 
    if err == io.EOF { 
        log.Fatal("read failed:", err) 
    } 
} 

必须要判断 err 是否和约定好的错误 io.EOF 相等。

再来一个例子，当我想返回 err 并且加上一些上下文信息时，就麻烦了：

在 readfile 函数里判断 err 不为空，则用 fmt.Errorf 在 err 前加上具体的 file 信息，返回给调用者。返回的 err 其实还是一个字符串。

造成的后果时，调用者不得不用字符串匹配的方式判断底层函数 readfile 是不是出现了某种错误。当你必须要这样才能判断某种错误时，代码的“坏味道”就出现了。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!