uber_go_guide解析(二) 前言 正文

接上回

正文

错误消息

Go中声明错误有几种方式

  • errors.New() 简单的声明静态字符串信息的错误
  • fmt.Errorf 可以格式化插入信息的错误
  • 自己实现 Error() 方法
  • 使用errors.Wrap
    在使用错误时,需要根据使用场景来判断哪种是适合的
  • 如果只需要简单的静态错误信息, 不需要额外的一些定制的错误信息, 只需要使用 errors.New() 即可
  • 需要错误的上下文, 或者加入些时间等动态信息, 使用 fmt.Errorf 即可
  • 如果客户端需要检测这个错误, 可以自己实现一个 Error() 方法,当然 errors.New() 也可以
    示例:
    将静态错误给客户端检测
    uber_go_guide解析(二)
前言
正文
    将动态错误给客户端检测
    uber_go_guide解析(二)
前言
正文
    建议如果错误提供给客户端,应当再定义一个检查是否是该错误的函数,而不是由客户端手动检测
    uber_go_guide解析(二)
前言
正文

错误包装

在包装错误时,要加上错误的上下文来增加可读性
包装错误时,注意不要添加多余的内容,比如
uber_go_guide解析(二)
前言
正文
但是注意,如果此错误需要和日志一起返回给客户端,则需要注意加上 filed 或者 err 来与普通日志进行区分

处理类型断言

在使用类型断言时,应当接收 ok 进行判断,如果不接受 ok 会引发panic
uber_go_guide解析(二)
前言
正文

不要引发Panic

一定要注意,在生产环境中运行的代码一定不要引发Panic,你可以返回err来让调用者安全的解决问题
但是在程序的初始化过程中出现问题则可以引发Panic来停止程序的执行
即使在编写test测试时,也不要直接写 panic 而是 t.Fatal 或者 t.FailNow

使用 go.uber.org/atomic

软广?

避免全局可变变量

一般的在全局变量初始化成功后不要修改他,可以创建局部变量代替
错误示范
uber_go_guide解析(二)
前言
正文
正确的
uber_go_guide解析(二)
前言
正文

避免在公共结构中嵌入类型

尽量少的使用继承
推荐用法
uber_go_guide解析(二)
前言
正文

性能

优先使用 strconv 而不是 fmt

我们将 int 转换成 str 时, 可以使用 fmt.Sprint() 也可使用 strconv.Itoa()
但是实际测试发现 strconv 效率要比 fmt 高不少
所以在转换时应使用 strconv
uber_go_guide解析(二)
前言
正文

避免字符串到字节的转换

不要总是将字符串转换成字节,如果目的是使用字节应当在建立时就指定字节
uber_go_guide解析(二)
前言
正文

尽量在初始化map时指定map的容量

尽可能的在make map时指定map的大小,这会减少未来的空间分配
uber_go_guide解析(二)
前言
正文