Logging as a code smell
dave.autonoma.ca
Logging as a code smell
1–10 of 54 posts
Re: Logging as a code smell
#2One way I've seen this going awry is when real functionality starts being built as event listeners. Data that would ideally be propagated back up the call stack instead just get consumed via published events because then the core logic doesn't have to be touched. It's like setting up an observatory with a parabolic antenna pointed at the mysterious legacy core, recording & processing its emissions to reconstruct the inner workings.
Re: Logging as a code smell
#3(1) This seems more than a bit Java-specific.
(2) Not all kinds of software can afford to depend on an event-publishing infrastructure. One obvious example is the event-publishing infrastructure itself. Less obviously, all of its transitive dependencies down to storage, networking, and operating systems.
(3) After dismissing logging and explaining a more complex event model, the author says in their own project he stripped away a lot of that infrastructure and ... reinvented logging. Similarly, they admit that AST-rewriting magic is a "footgun" and then recommends it. Why keep arguing for one thing and then doing the opposite?
(4) Tagging everything you don't like with buzzwords like "code smell" is a bit of a writing smell. It's "considered harmful" for millennials.
(5) The swipe at log4j seems to be just a misguided attempt to make the author's opinions seem more topical. The recent log4j vulnerability was not a problem with logging itself, but with a particular implementation that embedded some rather crazy functionality. That functionality could just as easily have been embedded in an event-oriented system, and I'll bet someone somewhere has already done exactly that.
Re: Logging as a code smell
#4I'm not sure this article does a good enough job of explaining why it's a code smell. Aside from the event bus code looking slightly better, I don't see any big advantages. One disadvantage is that if you have a big class with lots of different events, you now have to import all of your events rather than just importing the singular logger.
Typically I only resort to logging in situations where I don't want to propagate an error but I do want to log that an error happened. I also sometimes get lazy and debug using logs. I'm trying to avoid this as much as possible and instead debug by attaching to a process and using breakpoints. However this article doesn't touch on either of these scenarios.
Also, log4j's vulnerability had nothing to do with the actual concept of logging. AFAIK the vulnerability came from log4j's JNDI lookup functionality, which was not doing any kind of input sanitization which allowed attackers to perform remote code execution.
I was really looking forward to a post on logging as a code smell, mostly geared towards inexperienced developers. Pretty disappointed with the actual post.
Re: Logging as a code smell
#5> Logging is an example of code duplication.
Is it? What am I missing here?
Re: Logging as a code smell
#6I love the idea of an event bus, but all I use is C and embedded. The last time I considered it I backed away from it.
Wish there was effort to establish a pattern for this in C.
Re: Logging as a code smell
#7Just like a Java programmer to tell you to use an event bus for simple diagnostics. I’m a former one, I don’t mean no offense.
I go even lower though. Just
print(“XXXXXXXXXXX”)
print(“XXXXXXXXXXX”)
print(amount)
Re: Logging as a code smell
#8I'm not sure this article does a good enough job of explaining why it's a code smell. Aside from the event bus code looking slightly better, I don't see any big advantages. One disadvantage is that if you have a big class with lots of different events, you now have to import all of your events rather than just importing the singular logger. Typically I only resort to logging in situations where I don't want to propag…
Awful hard to attach a debugger to a production system?
Re: Logging as a code smell
#9In an ideal world, we wouldn't use logging to debug things after-the-fact. We would use traces, monitoring, and yes, events. But we don't always live in an ideal world, and logs are a simple and easy way to determine the sequence of events that happened after-the-fact, especially if there's something going on in a single application (which... happens to be a pretty big chunk of cases).
And at the end of the day, few things are more versatile than a big wall of text with timestamps and request ids attached. Saying that logging is a code smell is a little like saying all tech debt is bad.
Re: Logging as a code smell
#10I think the author is on the cusp of the right idea but misses it with the new implementation — the only meaningful change is switching fixed strings interpolated with data to fixed classes parametrized with data. It’s not nothing, but it’s basically a funny way to do structured logging. Logging systems are already event streams with the ability for consumers modify, add supplementary data, and route output with strategies, formatters, etc etc.
What I would rather see is a new keyword that generalizes the concept of logging in it’s entirety — “emit $object.”
For discrete events it would be emit ThingHappened(), for logs it would be emit Log(), and for traces it would be emit OpenSpan() and emit CloseSpan(). You could collapse whole classes of libraries into a few emit calls and a single listener.