GO 训练营第 2 周总结

go error 实践

error本质

error在go里是一个普通的值，可以根据inteface要求，自由扩展为开发者需要的信息。



原始error及其它相关异常实践

a. panic表示致命错误，意味着程序挂了，不能期望调用者去处理，一定不要使用panic去控制流程。

b. 服务启动，强依赖失败的话，可以使用panic

c. 与主流语言的区别在于多返回值，能把异常和结果作为不同字段一起返回

d. 野生goroutine不能被recovery

e. 请求里建议不要直接使用go协程去异步处理，可能会导致协程数量过多，可以将其chan到协程池去处理

f. 没有exception那种不受控制的流程，在go里，err也是一种普通的值，方法报err，能够直接在它下一步得知，缩小代码流程的控制范围。



error设计初衷

1. 考虑失败而不是成功，需要开发者首先关注error；

2. 没有隐藏的控制流，代码流程是线性的；



error实践的演进

a. 预定义错误（sentinel err），类似io.EOF。只是预定定义好的、固定的字符串信息，无法携带实际运行中运行的上下文信息，且需要调用者强耦合该错误。

b. err types，类似os.pathError。可以携带上下文信息，但调用者还是需要强耦合该类型，如：在判断错误的时候，一般都需要类型断言然后判断是否是该type。

c. 不透明的错误（opaque errors）。err只代表对和错两种情况，这是使用起来最简洁的方法，但它的缺陷还是不能携带更多的信息，如上下文 。

d. 不透明的错误升级版，构建自定义的错误，可以存放上下文等信息，再对外提供判断错误类型的方法（与之前的区别在于不是直接暴露错误类型让外面去断言）

f. 最佳实践：wrap error



wrap error

特点

1. 包含堆栈

2. 可添加自定义的error信息



规范

1. 基础库（第三方库、自行封装的基础库）不wrap，在业务依赖基础库的地方warp

2. 调用自己库内的方法，直接返回err，即错误没有被处理时，要返回错误

3. 如果错误被处理过（打日志也算），不能再向上返回，因为可能是功能降级。

4. 重点：错误只应该被处理一次，打日志也算是处理



作业

https://github.com/pauky/Go-000/blob/main/Week02/main01.go