[Rd] Error Reporting
ivowel at gmail.com
Tue Apr 24 14:13:22 CEST 2007
thank you, duncan. I get this particular error from subset(d,
select=c( list.of.many.variables.one.of.which.is.misspelled) ); this
is probably not too uncommon in data sets with many long-named
variables. hunting down what causes it is a pain. I am definitely
looking forward to 2.6.0 and hope that keeping source line numbers (as
"comment do nothing" statements?) in the evaluator will happen.
On 4/24/07, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> 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
> 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.)
More information about the R-devel