[Rd] Error Reporting

[Duncan Murdoch]

On 4/23/2007 7:23 PM, ivo welch wrote:
> Dear R developers:  May I suggest that future versions of R improve a
> little on the error reporting?  For example, right now, I am trying to
> figure out which of my column names in a select statement has been
> mis-spelled:
> 
> Error in `[.data.frame`(x, r, vars, drop = drop) :
>         undefined columns selected
> 
> It would be nice if it could say what the name of the undefined column is.

I think this message usually arises when you're doing something like

 > vars <- NA
 > df[1, vars]
Error in `[.data.frame`(df, 1, vars) : undefined columns selected

so the message is trying to tell you that there isn't any name 
available.  Conceivably the message could be clearer (e.g. in this 
specific case, "NA in column selection"), but that may not be the only 
way this error could arise.

> Of course, I have already begged a couple of times that errors like
> this be preceded by a backtrace or the last line number from the
> user's R program.
 >
 > joke.R:22: Error in `[.data.frame`(x, r, vars, drop = drop) :
 >         undefined columns selected: "non.existing.name" in 
"data.frame.name"
 >

That's quite difficult.  The parser knows line numbers, and can report 
them (as of 2.5.0), but these aren't kept when the lines are evaluated. 
  The sequence is:

read the file
parse it into a list of expressions
evaluate it

Parsing errors can report line numbers, but the evaluator doesn't keep them.

This means R doesn't have any idea what line caused a particular error. 
  In principle it could (e.g. by keeping line number info in functions), 
but it's tricky to get right, because there are so many ways to modify 
expressions after parsing.

There are limitations to the parser line number reporting (e.g. in a 
package, all source files are concatenated before parsing; if you have a 
syntax error you'll see the report about the concatenated file line 
number, not the original source file line number).  I'd say fixing those 
is the first priority.  My long range goal is to provide support for 
source-level debugging, which has requirements similar to the error 
reports you want:  they may come at the same time.  I'd guess this won't 
happen in 2.6.0, but you never know.

Duncan Murdoch

> I don't understand why this is difficult (simply storing the currently
> executing line and/or linenumber) as the program executes---but then,
> I am a lousy freerider who does not look at the code.  (All I do is
> occasionally donate to the R org.)
> 
> of course, I appreciate the great language you have put together.
> just begging to make it a little better.  (yes, I do not want to use
> ESS.)