[R] Line numbers with errors and warnings?

[Milan Bouchet-Valat]

Le dimanche 02 décembre 2012 à 09:02 -0500, Duncan Murdoch a écrit :
> On 12-12-02 8:33 AM, Milan Bouchet-Valat wrote:
> > 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?
> 
> The general rule is that parse() needs to be called with the "srcfile" 
> argument set to a srcfile object.  source() does that by default.
OK. But isn't it technically possible to compute a line number even when
no source file is present? If you call fix() on any function, you will
get something like a source file even if srcfile was not set. So it
could make sense to have a line number referring to what you would see
in fix(). Or at least, the last executed line when calling browser() or
when using options(error=recover), like gdb does.

This could be especially useful for packages that were not installed
with keep.source=TRUE. It could even help getting more useful error
messages on R-help...

Regards

> Duncan Murdoch
> 
> >
> >>> 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
> >
> > ______________________________________________
> > R-help at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
> >