@schwa Even more interesting when it is a container processing data in real-time... those printed logs give me a record I can look at after it has failed to see what happened before it failed.
@schwa They're going to have to pry printf from my cold, dead hands. It's amazing that it scales down to embedded devices (using a UART) and up to debugging race conditions in multithreaded code.
@schwa I often encourage reducing logging in favor of returning status as an enum or throwing an error. I prefer to have lower level API not log as much and instead communicate everything in a structured way to callers so code can handle the status or error. They can either choose to handle it, pass it up further or log it.
@schwa Once time an engineer in China flew into Seattle because his company had a critical deadline for a product launch. He was supporting a BLE device which kept failing to connect with the app my team supported. He had been getting a generic error for a long time and could not figure it out. Turns out 7 layers deep the specific was thrown and it went up to the top layer then was made generic and unhelpful. The problem was that when the BLE device connected it needed to send the version before continuing further and we had a specific error code but our protocol would not support passing back a useful error code. This is why I prefer to communicate with code because even if we did have logging this developer would not know to look for it. Instead a status code would have helped him understand exactly how to fix the problem.
Add comment