这是我参与「第五届青训营 」伴学笔记创作活动的第 15 天
- 如果错误是一套错误链，我们该如何处理呢？
- 还有一个errors.As方法，它和is的区别在于as会提取出调用链中指定类型的错误，并将错误赋值给定义好的变量，方便后续处理，示例中是把问题的path打印出来了
- 在Go中，比错误更严重的就是panic，它的出现表示程序无法正常工作了，那么在使用时应该注意什么呢？ 不建议在业务代码中使用panic。因为panic发生后，会向上传播至调用栈顶，如果当前goroutine中所有 deferred 函数都不包含recover就会造成整个程序崩溃。 若问题可以被屏蔽或解决，建议使用error代替panic 特殊地，当程序启动阶段发生不可逆转的错误时，可以在init或main函数中使用panic。因为在这种情况下，服务启动起来也不会有意义 比如示例是启动消息队列监听器的逻辑，在创建消费组失败的时候会Panicf，实际打印日志，然后抛出panic
- 有painc，自然就会提到recover，因为我们并不能控制所有的代码，避免不了引入其他库，如果是引入库的bug导致panic，影响到我自身的逻辑该如何处理？ 这里要注意recover的生效条件
- 常见情况是记录panic的调用栈信息，出现问题时能够方便分析定位 示例中的debug.Stack()包含的调用堆栈信息，方便定位具体问题代码
- 因为错误和异常是不正常的情况，除了希望程序能兼容这些场景外，重要的也有记录问题的上下文信息，方便后续定位原因 在明确panic recover这些功能的作用范围的情况下，编写更可靠的程序
- 接下来有个问题来回顾下之前的内容 首先是time，那个方法名更好，输入now或者nowtime，提示下，我们看看实际调用时是什么情况 time包的方法也是类似，Now和NowTime返回的是time.Time类型，使用时没有必要写成time.NowTime来额外表示时间信息，使用Now更简洁 注意这里持续时间并不是time类型，使用time.ParseDuration()返回的是time.Duration类型，这种情况在函数命名中体现是不冗余的，用ParseDuration更好 预计给大家20s时间，明确指令选择，大概30个反馈
