The reality is that there are a variety of debugging techniques that can be employed for each flavor and etiology of bug -- the major categories of which are: using external debuggers, instrumentation for logging, instrumentation for tracing (which is different -- another matter), automated analysis, and (at the bottom of the food chain) dump generation and code inspection. Each to its place and time.
Discussions about debugging and instrumentation techniques always seem to get doctrinaire -- witness xero314's shouting "DO NOT" re: logging and pushing a fad paradigm. Linus's eschewing of debuggers is as religious a stance as any, when, in fact, there are many times when using a debugger cuts to the chase in shortest order, as well as many times where single-stepping is useless.
Regarding logging, I agree: define your use cases, prototypical failure modes, and what your information extraction goals for instrumentation are, and design your logging scheme accordingly. My 25-year experience with this problem has shown at least the following as being highly desirable characteristics an any logging scheme, though:
* Detail level: Selecting the degree of verbosity at the point of generation of each log entry is essential; post-filtering can compensate for sheer volume, but choking this at the source is much preferable.
* Context: Generation of each log entry with a "component" tag (defined application-specifically) allows generation or filtration to be selected based on architectural scope as well, regardless of detail level. Why emit log entries whatsoever for the GUI when it's the core processing engine you're debugging?
* Uniformity: Consistent formatting of log output vastly simplifies visual comprehension and creation of ad-hoc log postprocessing/analysis utilities. (echoing Machtyn)
* Excisable: Implementing the logging scheme such that the code can be rebuilt sans the logging facility is especially important for performance-critical applications.
* Efficiency: For logging high-speed events, there may also be a need to buffer log entries in RAM and emit those periodically in bulk to the log capture facility, depending upon the throughput of that interface. This to avoid entry into a Heisenbergian realm of your logging facility affecting core application functionality. In some extremely high-speed/-volume cases, you can log very terse event representations to an standalone log server box which does contextual lookup and expansion externally.
OMG! With this being a new state of matter, being neither metal nor salt, and a dynamically changing crystalline structure, they've discovered... dilithium crystals!
Slashdot Mirror
Good points, all.
The reality is that there are a variety of debugging techniques that can be employed for each flavor and etiology of bug -- the major categories of which are: using external debuggers, instrumentation for logging, instrumentation for tracing (which is different -- another matter), automated analysis, and (at the bottom of the food chain) dump generation and code inspection. Each to its place and time.
Discussions about debugging and instrumentation techniques always seem to get doctrinaire -- witness xero314's shouting "DO NOT" re: logging and pushing a fad paradigm. Linus's eschewing of debuggers is as religious a stance as any, when, in fact, there are many times when using a debugger cuts to the chase in shortest order, as well as many times where single-stepping is useless.
Regarding logging, I agree: define your use cases, prototypical failure modes, and what your information extraction goals for instrumentation are, and design your logging scheme accordingly. My 25-year experience with this problem has shown at least the following as being highly desirable characteristics an any logging scheme, though:
* Detail level: Selecting the degree of verbosity at the point of generation of each log entry is essential; post-filtering can compensate for sheer volume, but choking this at the source is much preferable.
* Context: Generation of each log entry with a "component" tag (defined application-specifically) allows generation or filtration to be selected based on architectural scope as well, regardless of detail level. Why emit log entries whatsoever for the GUI when it's the core processing engine you're debugging?
* Uniformity: Consistent formatting of log output vastly simplifies visual comprehension and creation of ad-hoc log postprocessing/analysis utilities. (echoing Machtyn)
* Excisable: Implementing the logging scheme such that the code can be rebuilt sans the logging facility is especially important for performance-critical applications.
* Efficiency: For logging high-speed events, there may also be a need to buffer log entries in RAM and emit those periodically in bulk to the log capture facility, depending upon the throughput of that interface. This to avoid entry into a Heisenbergian realm of your logging facility affecting core application functionality. In some extremely high-speed/-volume cases, you can log very terse event representations to an standalone log server box which does contextual lookup and expansion externally.
OMG! With this being a new state of matter, being neither metal nor salt, and a dynamically changing crystalline structure, they've discovered ... dilithium crystals!