在使用golang写代码时,在遇到err值判断的时候,我们经常会用到 log.Fatal 和 log.panic 将错误信息进行日志输出的情况,不过遇到的错误一般会有两种:
- 一种是确实影响到了程序后面的执行,前后关联性比较强;
- 另一种是程序关联性并不强,当前的执行不成功或报错并不影响后面的执行,或者该错误并不会影响正常输出的结果。
遇到后者时,我们还是希望程序继续执行的(比如,进行for 死循环进行c/s交互时,因为网络短时中断或其他原因,暂时出错,实际我们是不希望程序退出的,还是希望循环继续,等待网络恢复后,程序继续)。
如下图,我们在执行df 操作时,遇到了Transport endpoint这样的输出错误,但并未影响到后面 df 结果的正常输出。这点也可以通过shell 编程中常用的 $? 判断进行确认(正常执行后的结果是0,出现异常时为非0),可以看到后面输出了1,而执行uptime没有报错,输出为0 。
比如在这台机器上,我们使用 golang调用某个脚本,里面有 df 取磁盘信息,刚好又加了如下的语句:
if err != nil {
log.Fatal(" script exec error is:", err)
}
那这时候就真的恭喜你中奖了,程序退出报错 —- 实际上呢,并不影响stdout的输出的。为什么会这样呢?看下官方文档的使用介绍:
上面说明的比较清楚吧,使用log.Fatal 和 log.Panic 相关的函数时,会调用os.Exit(1)退出程序。遇到这种情况怎么办呢?可以换用 log.Print 。该函数在输出日志的时候并不会调用os.Exit 进行退出。