Re: using the debugger

[Tim X]

rusi <rustompmody@gmail.com> writes:

> On Apr 8, 7:03 pm, "Drew Adams" <drew.ad...@oracle.com> wrote:
>> > while I'm stepping through the calling of a function, it in turn calls
>> > another function, which I don't really care about. I know what it's
>> > going to return, I just want to get on with things, but the secondary
>> > function is long and drawn-out and I have to hit "d" like
>> > fifty times to get through it and back to the top-level function.
>> > Can someone tell me how I can skip them?
>>
>> Use `c' to `c'ut to the `c'hase, skipping directly to the result of an
>> evaluation.
>>
>> Use `d' to `d'ig through an evaluation step by step.
>>
>> Remember the `C-h m' is your friend in nearly any buffer.
>>
>> [Ken's reply about "instrumenting" was no doubt about using `edebug'.  I 
>> take it
>> that you are instead using `debug' (which is what I use, FWIW).  IOW, I 
>> assume
>
> Just curious -- why do you prefer debug over edebug?
> Or perhaps a better question: Whats your debug-workflow?
>
>> you're either calling `(debug)' in your code or doing `M-x debug-on-entry' or
>> setting `debug-on-error' or `debug-on-quit' to non-nil.]
>

I can't answer why Drew uses debug, but I use it frequently simply because
for many problems it is sufficient and I find it easier than setting up
edebug. I tend to switch to edebug if the problem proves to be tricky 
and the problem is not revealing itself via reading the code or debug
isn't giving the level of control/interaction I need. 

Probably the most common 'tool' I use is message. I personally don't
like stepping through lines of code watching variables change value to
find a problem. My preferred approach is to study the code and trace
through it in my head as most of the time, I find the bugs that are the
trickiest to fix are more about logic problems and errors in the
algorithm. Really understanding what the code does is the key and I find
studying the source to be more rewarding than stepping/tracing through
lines of code with a debugger because that doesn't give a high
enough/overall view of what was intended - sometimes, you need to see
the forest and not the trees.

Tim


-- 
tcross (at) rapttech dot com dot au