Blog

Log Level: Extreme
Andrew McKnight – 30 October 2017

I recently updated my dependency on the excellent XCGLogger and noticed that in the jump from major version 4 to 6, a new log level appeared: SEVERE. Now, I already had a hard time when deciding between certain log levels for certain situations. The first rule in SOLID, separation of concerns, lends a helping hand by contextualizing our logs instead of overloading the spectrum of priority.

It’s Log™!

XCGLogger, and CocoaLumberjack before it, had 5 levels: verbose, debug, info, warn and error. Here are some loose rules I have for how to choose which level to use:

That being said, I have found exceptions to every rule, and often have trouble deciding which level to use. Usually though, the best indicator is how fast you’re able to sift through your own logs–or more painfully, what you’re missing.

Level playing field, slippery slopes

I don’t think I’m alone in my confusion. All sorts of blog posts have been written on the subject, outlining the author’s preferences and rules just as I have above. Of course, there’s plenty of discussion on Stack Overflow too.

As if it were bad enough trying to choose a log level, not all logging frameworks have the same amount of levels, or call equivalent levels by the same name:

The log stands alone

Individual contexts help relieve the need for more and more log levels. Adding levels seems like an attempt to cut through high amounts of noise to get to what’s really important. We want to minimize log size on disk while capturing essential information. Moving away from a monolithic log helps more here than adding log levels: it affords much more flexibility without adding more cognitive overhead at each call site.

In Trgnmtry, I had a need to log the CGPoint of a touch as it was dragging around the screen. This output a large amount of information to the log. At first I debated myself whether to log these at debug or verbose levels, but then it occurred to me that I could log them independently, using a different instance of my logging class. Now if I need to see those logs again I can flip them on and off independently without worrying about other information I might suppress or unleash.

Severely svelte

For now, I’m not spending time working in a new log level. Hopefully it’s helping folks out there instead of making things less clear. At least for now they won’t have to muck with creating customizations, which would require way more magical Swift code to write with type safety.


Enjoy the post? Please help support more like it by buying me a cup of coffee! I am also available for contracting.