Line numbers with errors and warnings?

Le dimanche 02 d?cembre 2012 ? 06:02 -0500, Steve Lianoglou a ?crit :

Hi,

On Sun, Dec 2, 2012 at 12:31 AM, Worik R <worikr at gmail.com> wrote:

What I mean is how do I get the R compilation or execution process to spit
out a line number with errors and warnings?

Indeed, I often suffer from the same problem when debugging R code too.
This is a real issue for me.

As Duncan mentioned already, you can't *always* get a line number. You
can, however, usually get enough context around the failing call for
you to be able to smoke the problem out.

What are the cases where you cannot get line numbers? Duncan said
source()ed code comes with line numbers, but what's the more general
rule?

option(error=browser) is a help.  But it still does not say what piece of
code caused the error.

I typically run with a slightly different setting:

R> options(error=utils:::dump.frames)

Whenever my script throws an error, after I'm done cursing at it I
then wonder where this error happened, so I call:

R> traceback()

And you'll see the details of the stack that just blew up, starting
(or ending, can't remember) with the call itself, then the parent
call, and its parent, etc. all the way up to the top most call (likely
the line in your script itself).

If that's not enough information for me to figure out how to fix the
code in my script, I'll then call:

R> debugger()

and this will then give me (more or less) the same information that
`traceback` showed (but in reverse order (which is why I never
remember the order of traceback)) and you are asked at what point
you'd like to enter the exploded wreckage to explore (via picking a
number) ... this way you can poke at the local variables until you see
what went wrong.

This is very useful of course to find the problematic function, but
quite often I end up wondering what exact command triggered an error.
For example, "subscript out of bounds" is hard to match to a precise `['
use in a whole function.

Even when using browser(), sometimes you cannot know where you are in
the function. So the line number, or the contents of the last line,
would be relevant information.

Your error:

Error in `[.xts`(x, xsubset) : subscript out of bounds

Is suggesting that you are trying to index an `xts` object with an
illegal value -- can you find the part in your code that's trying to
do this in your own script? You can put a call to `browser()` before
that part and explore the value of the subscript vs. the length of
your xts object to see what the problem is.

If you can't find this point, then take the traceback/debugger route.

This is costing me a lot of time chasing down errors in mine and others
code...

... which is typical when your wading in uncharted territory. As you
get a better feel of how to resolve these issues, your time-to-fix
these things will get better, so ... stay strong.

Of course experience helps, but without the most relevant information
(line number) you productivity is always affected... ;-)


Regards