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.
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"
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.)
regards,
/ivo
Error Reporting
3 messages · Duncan Murdoch, ivo welch
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.)
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. regards, /ivo
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
"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.)