go错误和异常
错误和异常是两个不同的概念，但我们在开发中又非常容易混淆这两个概念，把一切非正常情况都看做是错误，而不区分错误和异常，即使程序中有异常抛出，也将异常即使捕获并转换成错误；因此： 我们的明确什么是错误，什么是异常；
错误：指可能出现问题的地方出现了问题，即这种情况在人们的预料之中
异常： 指不应该出现问题的地方出现了问题，这种情况在人们的预料之外
golang语言中使用了error来表示错误，使用panic抛出异常，通过defer和recover函数来捕获异常，
Golang错误和异常的互相转换：
1. 错误转异常，比如程序逻辑上尝试请求某个URL，最多尝试三次，尝试三次的过程中请求失败是错误，尝试完第三次还不成功的话，失败就被提升为异常了。
2. 异常转错误，比如panic触发的异常被recover恢复后，将返回值中error类型的变量进行赋值，以便上层函数继续走错误处理流程。
1、异常处理场景
1. 空指针引用
2. 下标越界
3. 除数为0
4. 不应该出现的分支，比如default
5. 输入不应该引起函数错误
2、错误处理的正确姿势
- 失败的原因只有一个时，不使用error
- 没有失败时，不使用error
- error应放在返回值类型列表的最后
- 错误值统一定义，而不是跟着感觉走
- 错误逐层传递时，层层都加日志
- 错误处理，使用defer释放资源
- 当尝试几次可以避免失败时，不要立即返回错误
- 当上层函数不关心错误时，建议不返回error
- 当发生错误时，不忽略有用的返回值
３、异常处理的正确姿势
- 在程序开发阶段，坚持速错
- 在程序部署后，应恢复异常避免程序终止
- 对于不应该出现的分支，使用异常处理
- 针对入参不应该有问题的函数，使用panic设计
４、golang常用的debug工具
- ContentsMemStats and GC
- PProf
- Trace
- GDB and Delve
** 4.1. MemStat & GC**
首先先获得一些基本的信息，内存使用和GC情况。
MemStats:
// read mem stats
var m runtime.MemStats
runtime.ReadMemStats(&m)
GC:
// disable gc when start
GOGC=off go run main.go
// disable gc and manually trigger gc
debug.SetGCPercent(-1)
runtime.GC()
// read gc stats
var g debug.GCStats
debug.ReadGCStats(&g)
MemStats中我们关注的是Alloc/HeapAlloc，这个值代表了当前heap的大小，另外就是HeapObjects，代表了当前heap中有多少个对象，同时应该关注一下Frees，这个值代表了一共释放过多少的对象，可能当前内存使用已经降下来了但过去某个时间曾经升高过。同时可以结合GCStats查看一下GC的情况， LastGC代表了上次GC时间，NumGC代表了一共GC过多少次，PauseTotal总暂停时间以及Pause暂停历史。
4.2. pprof
MemStats和GCStats可以给我们一个大概的情况，但是更具体的信息，例如哪里耗内存最多，哪里耗CPU更多，我们需要更准确的情况，可以使用自带的pprof。
// CPU
pprof.StartCPUProfile(os.Stdout)
defer pprof.StopCPUProfile()
go run main.go > cpu.profile
go tool pprof cpu.profile
// Mem
pprof.WriteHeapProfile(os.Stdout)
go run main.go > cpu.profile
go tool pprof cpu.profile
同理，memory.profile给我们的也是当前的内存使用情况，有些时候并不适合debug，如果想知道全部的分配情况：
go tool pprof --alloc_space memory.profile
除了问题原因比较明确或者比较容易复现的情况，上面输出memory和cpu profile的情况有些时候并不那么实用，这个时候一方面我们可以结合上面的MemStats使用，如果达到某个值就输出一份profile，或者直接使用下面的通过web ui把profile信息实时输出：
// In time
import _ "net/http/pprof"
func main(){
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()
}
// http://localhost:6060/debug/pprof/
// - allocs: 这个跟上面的--alloc_space是一样的，同时还可以查看到MemStats
// - block: 没有在运行的时间，例如等待channel，等待mutex等。
// - cmdline: 当前程序的启动命令
// - goroutine: goroutine的信息
// - heap: 等同于上面的memory profle
// - mutex: Stack traces of holders of contended mutexes
// - profile: 等同于上面的CPU Profile
// - threadcreate: 线程
// - trace: 见下面trace部分
依旧可以使用工具来查看：
go tool pprof --alloc_space http://localhost:6060/debug/pprof/heap
除了实时分析外，还可以导出调用栈的图表：
go tool pprof -web/pdf/gif/dot/png... cpu.profile
或者直接在浏览器实时查看：
go tool pprof -http [host]:[port] [options] [binary] <source>
**4.3. traceprofile **
go程序可以给我们一些直观的输出，例如时间用在哪里，内存用在哪里，但是更加深层次的原因，例如一个web服务器为什么响应时间总是很久，pprof和trace主要的区别还是维度不太一样，一个更像是代码栈层面的，一个是更横向的。trace更关注与latency。
比如说一个请求在client观察从发送到完成经过了5s，做profile可能发现这个请求的CPU时间只有2s，那剩下的3s就不是很清楚了，profile更侧重的是我们代码执行了多久，至于其他的，例如网络io，系统调用，goroutine调度，GC时间等，很难反映出来。
生成trace可以通过下面的代码：
trace.Start(os.Stdout)
defer trace.Stop()
go run main.go > app.trace
go tool trace app.trace
或者上面的pprof的web ui也支持下载trace。
在trace上可以清楚的看到每个goroutine的起始，怎么生成的，每个cpu内核在做什么这些。
4.4. gdb & delve
对于百分之80的情况，上面的工具就已经足够了，有些极端的情况依旧无法避免，例如说我们的程序已经无响应了，那么即使开了实时的web ui，也是打不开的，这个时候就需要经典的gdb了。
gdb --pid=pid [executable]
gcore pid // 保存core dump
GDB是很大的一个topic，而且也有很多资源是介绍GDB的，关于GDB+go的使用可以直接查看官方文档：https://golang.org/doc/gdb， 而更多GDB的使用直接Google。
GDB比较通用，不是很能直接反映出go语言的特点，例如goroutine。所以也可以使用delve，delve可以理解为go版本的gdb：
dlv debug // 以dlv方式运行，跟go run一致
dlv test // 以dlv方式运行测试 跟go test一致
dlv exec [executable]// 以attach方式运行一个编译好的binary
dlv attach pid [executable] // attach到一个运行中的进程 貌似会暂停进程?
同时，delve也可以查看gdb保存的core文件：
dlv core [executable] [core file]
对比GDB来说，比较有特色的命令有两个（gdb也有这个）：
(dlv) goroutines
(dlv) goroutine [goroutine-id]
可以用来查看具体的goroutine信息。
全部命令可以参考 https://github.com/go-delve/delve/blob/master/Documentation/cli/README.md
参考原文链接：
https://www.cnblogs.com/zhangboyu/p/7911190.html
https://www.zhihu.com/question/40980436/answer/767289819
有疑问加站长微信联系（非本文作者）
