golang下慎用log.Fatal和log.Panic

2018年12月21日 发表评论 阅读评论

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

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

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

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

stderr

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

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

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

log-fatal-exit

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




本站的发展离不开您的资助,金额随意,欢迎来赏!

You can donate through PayPal.
My paypal id: itybku@139.com
Paypal page: https://www.paypal.me/361way

  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.