Breakpoint debugging is available in some of the more feature-rich IDEs such as those from Borland, Zend and the like. While this is a tool, it's also a technique.
A good breakpoint debugging technique draws on excellent logic tools for dividing the problem space and getting the most information out of a give question using trial and error.
Breakpoints enable you to stop the code running at a particular point, see what's going on and learning from what you've seen. You give a line number of function reference and the whole thing hangs there waiting for you to see what the hell went on on the way of the circus.
To many web developers this is like magic. While the C and Java families of languages (the "proper" languages..?) have had these in their IDEs for years, it's very much lacking from a lot of other environments.
Even when it's there, to get the most out of it you have to use an excellent trial and error technique.
Use trial and error and differential diagnosis to get the most useful values out of the runtime in one hit. If these turn out to be useful in diagnosing many problems, they should probably end up in the logs.
In fact, breakpoint debugging is just like ad hoc logging. You didn't know what would be important when you wrote the code so you use breakpoints to grab any piece of information in the hope it'll help.
This also helps understand code coverage: what is really being executed. If 90% of what happens at runtime depends on a single value, this is the way of find it out.
