4 ms·

I prefer good logging to debuggers. Often, you can't attach a debugger to the production system, but you can get logs. Also, you are often interested in the wh

I prefer good logging to debuggers. Often, you can't attach a debugger to the production system, but you can get logs. Also, you are often interested in the whole sequence of events leading up to the problem, not just the current state. And, to find where to look in the first place, you need to get an idea of what's wrong - a debugger doesn't help with that. https://henrikwarne.com/2014/01/01/finding-bugs-debugger-versus-logging/ https://henrikwarne.com/2014/01/01/finding-bugs-debugger-ver...

emsy 7y ago
Those are orthogonal to each other and you should use both. But in development, a good debugger with data breakpoints, logging and conditional breakpoints is much more focused than an overly verbose log.
- henrik_w 7y ago
  It's not overly verbose, and it's something you need anyway.
  - emsy 7y ago
    Overly verbose in the context of debugging. Logs almost can't be too verbose, because as you said, they should be able to tell you the sequence of events that lead to the error.
deleted 7y ago
[deleted]
sfink 7y ago
Logging always has a tradeoff between utility and overhead. It would be great to log everything, but it would impact performance too much. So you end up with logging levels, categories, release-only logs, etc. Pernosco has something for that too. Since it has replay capability, it can replay with more logging than the original execution had. So to some degree, you can have your cake and eat it too. It's not perfect: I think it requires some level of integration with a given logging system, it's not going to do the full I/O to send your logs to where they would ordinarily go (syslogd or whatever), and you can't log values with debug-only code that wasn't compiled into the binary. But it's still a large boost to the fundamental tension around logging.
roca 7y ago
One of the points of the OP as that a really good debugger does capture and show you "the whole sequence of events leading up to the problem". It's totally understandable that people prefer good logging to traditional debuggers which really suck. But you have missed the point of the OP that much better debuggers are possible.

emsy 7y ago

Those are orthogonal to each other and you should use both. But in development, a good debugger with data breakpoints, logging and conditional breakpoints is much more focused than an overly verbose log.

henrik_w 7y ago
It's not overly verbose, and it's something you need anyway.
- emsy 7y ago
  Overly verbose in the context of debugging. Logs almost can't be too verbose, because as you said, they should be able to tell you the sequence of events that lead to the error.

deleted 7y ago

[deleted]

sfink 7y ago

Logging always has a tradeoff between utility and overhead. It would be great to log everything, but it would impact performance too much. So you end up with logging levels, categories, release-only logs, etc. Pernosco has something for that too. Since it has replay capability, it can replay with more logging than the original execution had. So to some degree, you can have your cake and eat it too. It's not perfect: I think it requires some level of integration with a given logging system, it's not going to do the full I/O to send your logs to where they would ordinarily go (syslogd or whatever), and you can't log values with debug-only code that wasn't compiled into the binary. But it's still a large boost to the fundamental tension around logging.

roca 7y ago

One of the points of the OP as that a really good debugger does capture and show you "the whole sequence of events leading up to the problem". It's totally understandable that people prefer good logging to traditional debuggers which really suck. But you have missed the point of the OP that much better debuggers are possible.