The Dangers of Fatal Logging

I want to talk about fatal logging. It’s practically always a bad idea. Let me explain…

I was recently reviewing some code written in Go, where I saw this pattern in a constructor function:

func NewConnection(url string) *Client {
    conn, err := service.Connect(url)
    if err != nil {
        log.Fatal( err)
    }
    return &Client{conn: conn}
}

Whatever language you use, if your logging library has a Fatal option, I emplore you to never use it, and for one simple, but profound reason:

It Violates the Single-Responsibility Principle

Now, I don’t generally put the SOLID principles on a high pedestal. But this is one place where the SRP violation doesn’t just peek through the curtains, asking you politely to reconsider. It bursts through the seams like the Kool-aid Man screaming for attention. Oh yeah!

In Go, calling log.Fatal in the standard library, and to my knowledge in any other logger implementation, does two things:

1. It logs an error message with a priority of FATAL
2. It immediately exits the program (by calling os.Exit(1))

Do you see the SRP violation?

Logging is one concern. Affecting the control flow of the entire program (by exiting) is something else entirely. This function, by design, has two unrelated responsibilities.

But does it matter? If you know that calling log.Fatal exits the program, surely you can make an informed decision, right?

If you’re writing some short, throw-away program, akin to a bash script, sure. Whatever. I often have no problem violating the SRP, or countless other rules of thumb and best practices in such a case.

But if you’re writing anything like a real application, this SRP violation creates an insideous form of tight-coupling in your program.

What if the caller of your function wants to try to recover from an error? Maybe you add an option for the user to provide a list of connection URLs, and you want to try all of them until one works.

for _, url := range config.URLs {
    conn = NewConnection(url)
}

With our current implementation, the first failure will cause the program to crash.

“Yes, but I can edit it!” You can. But SRP. You should have only one reason to change a piece of code. We now have two: (1) we want to change the way a connection works (2) we want to decouple control flow.

Or what if you add the option to re-connect to the service after a failure after the app has already been running. Do you want a failed connection attempt to exit the program? Well… maybe. But also maybe not. That should be up to the caller of the function, not the function itself.

Only Exit Your Program From the Top of the Call Stack

In Go parlance, this means: Only ever call os.Exit() from your main() function. This precludes calling log.Fatal from anywhere except possibly in main() itself.

If you follow this simple rule, your constructors will not surprise their callers by exiting the program.

This is doubly important in any language (like Go), where exiting the program precludes any cleanup. In Go, calling os.Exit means that deferred functions don’t get called, and there’s no opportunity for recovery. It’s final. Do not pass Go. Do not collect $200.

func NewConnection(url string) (*Client, error) {
    conn, err := service.Connect(url)
    if err != nil {
        return nil, err
    }
    return &Client{conn: conn}, nil
}