golang下慎用log.Fatal和log.Panic

在使用golang写代码时，在遇到err值判断的时候，我们经常会用到 log.Fatal 和 log.panic 将错误信息进行日志输出的情况，不过遇到的错误一般会有两种：

• 一种是确实影响到了程序后面的执行，前后关联性比较强；
• 另一种是程序关联性并不强，当前的执行不成功或报错并不影响后面的执行，或者该错误并不会影响正常输出的结果。

遇到后者时，我们还是希望程序继续执行的（比如，进行for 死循环进行c/s交互时，因为网络短时中断或其他原因，暂时出错，实际我们是不希望程序退出的，还是希望循环继续，等待网络恢复后，程序继续）。

如下图，我们在执行df 操作时，遇到了Transport endpoint这样的输出错误，但并未影响到后面 df 结果的正常输出。这点也可以通过shell 编程中常用的 $? 判断进行确认（正常执行后的结果是0，出现异常时为非0），可以看到后面输出了1，而执行uptime没有报错，输出为0 。

比如在这台机器上，我们使用 golang调用某个脚本，里面有 df 取磁盘信息，刚好又加了如下的语句：

1if err != nil {
2    log.Fatal(" script exec error is:", err)
3}

那这时候就真的恭喜你中奖了，程序退出报错 —- 实际上呢，并不影响stdout的输出的。为什么会这样呢？看下官方文档的使用介绍：

上面说明的比较清楚吧，使用log.Fatal 和 log.Panic 相关的函数时，会调用os.Exit(1)退出程序。遇到这种情况怎么办呢？可以换用 log.Print 。该函数在输出日志的时候并不会调用os.Exit 进行退出。