When debugging a function I usually use
library(debug)
mtrace(FunctionName)
FunctionName(...)
And that works quite well for me.
However, sometimes I am trying to debug a complex function that I don’t know. In which case, I can find that inside that function there is another function that I would like to “go into” (“debug”) – so to better understand how the entire process works.
So one way of doing it would be to do:
library(debug)
mtrace(FunctionName)
FunctionName(...)
# when finding a function I want to debug inside the function, run again:
mtrace(FunctionName.SubFunction)
The question is – is there a better/smarter way to do interactive debugging (as I have described) that I might be missing?
p.s: I am aware that there where various questions asked on the subject on SO (see here). Yet I wasn’t able to come across a similar question/solution to what I asked here.
Not entirely sure about the use case, but when you encounter a problem, you can call the function
traceback(). That will show the path of your function call through the stack until it hit its problem. You could, if you were inclined to work your way down from the top, calldebugon each of the functions given in the list before making your function call. Then you would be walking through the entire process from the beginning.Here’s an example of how you could do this in a more systematic way, by creating a function to step through it:
Here’s a dummy example of using it:
IMO, that doesn’t seem like the most sensible thing to do. It makes more sense to simply go into the function where the problem occurs (i.e. at the lowest level) and work your way backwards.
I’ve already outlined the logic behind this basic routine in “favorite debugging trick”.