✳flâneur — a map of the web's best reading

The Dangers of Fatal Logging - Jonathan Hall

jhall.io · 937 words · saved by 1 readers

I was recently reviewing some code written in Go, where I saw this pattern in a constructor function: 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: Now, I don’t generally put the SOLID principles on a high pedistal. But this is one place where the SRP violation doesn’t just peak through the curtains, asking you politely to re-consider. 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: Do you see the SRP violation? Logging is one concern. Affecting 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 writting some short, th

The Dangers of Fatal Logging - Jonathan Hall Blog / Coding Practices The Dangers of Fatal Logging February 26, 2022 log.Fatal violates the Single Responsibility Principle in insidious ways. Never use it! 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 loggin

Explore this link on the map →

related reading