Purposefully debugging without using a debugger?

Question

In chapter 5 of \"The Practice of Programming\" Brian Kernighan and Rob Pike write:

As a personal choice, we tend not to use debuggers beyond getting a st

Answer 1

Having to go to the debugger is a likely sign of a deeper problem in my view.

Before firing up the debugger, I ask questions that target deeper problems like:

• Which test failed? If the answer is, "there is no test," then not having a test for the failure condition is a deeper problem to be fixed first.

• What information does the exception have? (This assumes an environment with exceptions). If the answer is, "there is no exception," or the exception doesn't have much context, then scanning for places where an exception is swallowed, or adding more context to an exception is a deeper problem to be fixed first.

• What warnings are produced by the build for that section of the system? If you're not building and analyzing your system with modern tools to find common mistakes, and correcting them before they show up at runtime, then you've got a deeper problem to be fixed first.

• Do we understand the problem domain enough to reason about what might be happening? If the answer is, "no we're not clear on this," then discussions with subject matter experts who can make the purpose of a piece of the system more clear is in order. Without clearly understood requirements, more bugs will likely come.

Doing these sorts of things usually leads to at least one bug fix, if not several. And these approaches have the highly valuable side-effect of, well, forcing programmers to think about the problem, the whole problem, not just the line of code "where the error occurred."

Certainly there are cases where an error occurs on a single line like not checking for a null pointer/reference, etc. but aren't those "simple" errors the very types of errors that modern IDEs and tools help to eliminate? Just run a lint/static-analysis tool and heed the warnings - you won't get those types of errors anymore. Then you're left with things like design errors that require the reasoning of a human mind - how can a debugger figure that out?