3.4.2.1 How Breakpoints Work and Why They Are Useful

Often, debugging the last error is not enough to tell you what went wrong. For example, the root cause of the error may have arisen a long time before the error was signalled, in which case the execution context of the error is too late to be useful. Or your program might not signal an error at all, just return an unexpected result or have some incorrect side effect.

In many such cases, it's useful to pause the program at or before the point where you suspect the problem arises. Then you can explore the stack, display the values of key variables, and generally check that the state of the program is as you expect. If all is well, you can let the program continue running normally, or step more slowly through each expression that the Scheme interpreter evaluates. Single-stepping may reveal that the program is going through blocks of code that you didn't intend — a useful data point for understanding what the underlying problem is.

Telling Guile where or when to pause a program is called setting a breakpoint. When a breakpoint is hit, Guile's default behaviour is to enter the interactive debugger, where there are now two sets of commands available:

• all the commands as described for last error debugging (see Debug Last Error), which allow you to explore the stack and so on
• additional commands for continuing program execution in various ways: next, step, finish, trace-finish and continue.

Use of the interactive debugger is described in Interactive Debugger.