[Rd] Error Reporting

[ivo welch]

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