dongqiuxu2270
2015-11-24 04:02
浏览 146
已采纳

Go软件包应该在什么时候使用log.Fatal?

I have so far avoided use of log.Fatal, but I recently co-incidentally discovered these questions; code-coverage and tests-using-log-fatal.

One of the comments from the 100 code coverage questions says:

... In the vast majority of cases log.Fatal should be only be used in main, or init functions (or possibly some things meant to be called only directly from them)"

It go me thinking, so I began to look at the standard library code provided with Go. There are lots of examples where the test code in the library makes use of log.Fatal which seems fine. There are a few examples outside of the test code, such as in net/http, shown below:

// net/http/transport.go 
func (t *Transport) putIdleConn(pconn *persistConn) bool {
    ...
    for _, exist := range t.idleConn[key] {
        if exist == pconn {
            log.Fatalf("dup idle pconn %p in freelist", pconn)
        }
    }
    ...
}

If its is best practice to avoid use of log.Fatal, why is it used at all in the standard libraries, I would have expected just return an error. It seems unfair to the user of the library to cause os.Exit to be called and not providing any chance for the application to clean-up.

I may be naive, so hence my question as a better practice would seem to be to call log.Panic which can be recovered and my theoretical long running stable application might have a chance of rising from the ashes.

So what would best-practise say for Go about when should log.Fatal should be used?

图片转代码服务由CSDN问答提供 功能建议

到目前为止,我避免使用 log.Fatal ,但最近我碰巧遇到了 发现了这些问题; 代码覆盖tests-using-log-fatal

来自100个代码覆盖率问题的评论之一说:

...在大多数情况下, log.Fatal 仅应在main函数或init函数中使用(或可能某些只能直接从它们中调用的东西)”

这让我开始思考,因此我开始研究Go随附的标准库代码。很多示例中,库中的 test 代码都使用了 log.Fatal 看起来不错,测试代码之外还有一些示例,例如 net / http ,如下所示:

  // net / http / transport.go 
func  (t * Transport)putIdleConn(pconn * persistConn)bool {
 ... 
表示_,存在:=范围t.idleConn [key] {
如果存在== pconn {
 log.Fatalf(“ dup 空闲列表中的闲置pconn%p“,pconn)
} 
} 
 ... 
} 
   
 
 

如果最好的做法是避免使用 log.Fatal ,为什么在标准库中完全使用它,我希望可以返回 一个错误。 对于库的用户来说,导致调用 os.Exit 而不为应用程序进行清理没有任何机会似乎是不公平的。

我可能 天真,所以我的一个更好的实践问题是似乎可以调用 log.Panic ,它可以恢复,并且我的理论上长期运行的稳定应用程序可能会灰飞烟灭。 p>

那么,最好的实践对Go应该说什么日志应该使用。应该使用致命的?

  • 写回答
  • 好问题 提建议
  • 追加酬金
  • 关注问题
  • 收藏
  • 邀请回答

1条回答 默认 最新

  • dongliao4353 2015-11-24 09:40
    已采纳

    It might be just me, but here is how I use log.Fatal. As per UNIX conventions, a process which encounters an error should fail as early as possible with a non-zero exit code. This lead me to the following guidelines to use log.Fatal when…

    1. …an error happens in any of my func init(), as these happen when the imports are processed or before the main func is called, respectively. Conversely, I only do stuff not directly affecting the unit of work the library or cmd is supposed to do. For example, I set up logging and check wether we have a sane environment and parameters. No need to run main if we have invalid flags, right? And if we can not give proper feedback, we should tell this early.
    2. …an error happens of which I know is irrecoverable. Let's assume we have a program which creates a thumbnail of an image file given on the command line. If this file does not exist or is unreadable because of insufficient permissions, there is no reason to continue and this error can not be recovered from. So we adhere to the conventions and fail.
    3. …an error occurs during a process which might not be reversible. This is kind of a soft definition, I know. Let me illustrate that. Let's assume we have an implementation of cp, and it was started to be non-interactive and recursively copy a directory. Now, let's assume we encounter a file in the target directory which has the same name (but different content) as a file to be copied there. Since we can not ask the user to decide what to do and we can not copy this file, we have a problem. Because the user will assume that the source and the target directories are exact copies when we finish with exit code zero, we can not simply skip the file in question. However, we can not simply overwrite it, since this might potentially destroy information. This is a situation we can not recover from per explicit request by the user, and so I'd use log.Fatal to explain the situation, hereby obeying the principle to fail as early as possible.
    评论
    解决 无用
    打赏 举报

相关推荐 更多相似问题