Should a Go package ever use log.Fatal and when?

Solution 1:

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.

Solution 2:

Marcus, I came across your response, and I think its excellent and very insightful, and I tend to agree with your breakdown. It is very hard to generalize, though I have been thinking about it this a little more, and as a newbie to Go. I think on a theoretical level, if we are looking to best practices in computing, regardless of OS, package framework or library, a logger's responsibility is to simply log. On any level, a logger's responsibilities:

• Format and print information consistently to the channel of my choosing.
• Categorize, filter, display the different log levels [debug, info, warn, error]
• Handle and aggregate log entries across async and parallel jobs

A logging package or any package does not and should not have authority to crash a program, if it is operating properly. Any middleware or library should follow a throw / catch pattern, with an opportunity for all exceptions thrown to be caught by the caller. This is also a good pattern to follow within an application, as you build foundations and packages that power various parts of your application, and potentially other applications, they should never crash an application directly. Rather, they should throw a fatal exception, allowing the program to handle. I think this also addresses some of your points Marcus, as it works to alert the caller immediately when uncaught, as a fatal crash.

For the most part I can enjoy leveraging log.Fatal in Go directly for the purposes of direct user facing cli tools, which I think is the simplicity it was truly intended for. I don't think it makes good sense as a long term approach to handle fatal errors across packages.