Software Design by Example 20: Debugger


The penultimate chapter of Software Design by Example explores one of the question that sparked this book: how does an interactive breakpointing debugger work? The first time I saw one in action I was completely baffled. How could the computer stop where I wanted and then keep going? How could it interact with me? Finding out was a lot harder than it should have been: there were (and are) lots of books and courses on compilers and operating systems, but nothing that explained the workings of this magical, powerful tool.

This chapter answers my long-ago questions by building a simple single-stepping debugger It also shows how to create unit tests for interactive applications. That’s a lot to pack into just two thousand words, but most of the ideas have come up before.

I’m pleased that I was able to answer my younger self’s questions. However, I’m still annoyed by the way debuggers are mostly left out of the curriculum. Of the forty-odd students I interviewed for software engineering intern positions last year, fewer than a dozen knew how to set a breakpoint in an IDE. Andreas Zeller’s The Debugging Book has a very informative chapter, and I recommend the whole book to every working programmer, but I’ll believe our profession is serious about building code that works when every undergraduate computer science program has a full-semester course on how to use tools to find and fix bugs.

Testing interactive application
Figure 20.2: Replacing input and output to test interactive applications.

Terms defined: breakpoint, source map, tab completion, watchpoint.