(#bqxlviq) I forgot one thing. Testing for errors is also an important part that is often overlooked in my experience. Another rule we talked about two hours ago is to test error messages preferably exactly. Then there’s a dim chance of spotting a final garbage error message. When seen in total, one might tell if it is understandable and all important context information are present. Lots of error messages I’ve come across are completely useless, I’ve no idea what’s going on or what I have done incorrectly. A frightening lot of times messages don’t even make any sense at all. Not a single bit. Just random words put together. The really bad ones you don’t understand even if you look at the code and exactly know what the situation is but still cannot decipher the message with all that knowledge on top. It happens more often that I would think.

No doubt, writing good error messages is an art in itself and often takes a minute or two (or even more) to come up with something short and still precise. But in the end it will always pay off to provide some quality message. Same with logging in general, of course. But errors returned to somebody else are more important than internal logs.

In a previous commercial software project the customer wanted to have a complete catalog of all info log messages and above. An additional description with more context had to be provided what that log ID and message meant. I think with warning level and above both a solution and verification was required on how to fix it and then validate that it actually worked. Error and fatal included even more stuff I can’t remember anymore.

For us developers that was incredibly annoying, but when we then finally also had to operate that software, this was absolutely awesome to have! Man, did I suddenly understand what all this effort was for. It immediately paid off. There was one guy inhouse just analyzing logs from our different systems all day long and trying to categorize and correlate things. Even with the log message catalog he often had some detail questions to use developers. Can’t imagine what would have happend without that catalog.

That experience was truely an eye-opener for me. I can also see it with my current work mates. Only if you had been forced to analyze yourself with nothing else but the logs what was going on or went wrong, you will appreciate and also write good messages yourself. If you haven’t been in that situation before, there’s basically no way you’ll be in a position to write decent logs. And even then you realize that important context is missing when you have to analyze something. :-)

I’m on the fence with testing log entries. In a previous project we quite often did. But there were also hard requirements to produce certain logs, so then it made sense. Usually I don’t unless there are some weird circumstances. Can’t think of any such situation off the top of my head right now, though.