[R] Line numbers with errors and warnings?

[Duncan Murdoch]

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.

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.
>