31–40 of 54 posts
(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 st…
It's a good point but I think the author sort of drove past the key insight. This is called structured logging. Having some kind of consistent schema of log messages is much better than plain strings for analysis later. It's just building a loose schema of events/log types, and picking a serialization format for said schema. JSON is popular because it remains human readable as well. I agree though, it really is very…
> Logging is an example of code duplication. Is it? What am I missing here?
I think the idea is you have: (1) Some code that does a thing (2) Another line of code that logs that the thing happened And, like in-lined documentation, the code can diverge from the text that says what it does.
(1) Some code that does a thing
(2) Another line of code that sends an event that the thing happened
Earlier quoted context omitted.
when my code is not working how i expect it to, i print a ton of equal signs, then the value on a knew line, then a new row of equal signs. never used loggin before.
You my friend need to experience an interactive debugger.
TL;DR: Log impure actions. If you minimize and group side effects, you don't need to log as much. Pure functions can be recomputed any time if you know their inputs.
Event buses can be useful, but it's hard to look at an event being published and know what it does and whether it's important. Whereas the importance of a logger call is usually pretty clear. Logs are rarely load-bearing, but an event can mean anything.
I'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?
> eases the transition to internationalized log messages
You don't internationalize debug traces any more than you internationalize your function names or programming language words. You barely even fix spelling mistakes in trace messages. Often, you build software without them at all: "compile them out".
One excellent reason not to use events for trace messages is that you may sometimes want every last trace message leading up to a crash to be recorded, which won't happen if they go through an event system where they sit in a queue which is no longer being serviced since everything died.
Oh, and your shiny event system could have issues, debugging which could benefit from trace messages.