R devel - Apr 2004 - More user-friendly error message needed.

When I tried the following commands, I got a strange message.

> x<-data.frame(y=c(1:10))
> plot(x$z)
Error in xy.coords(x, y, xlabel, ylabel, log) :
        x and y lengths differ

"The data frame, x, does not have a field named z."
may be better user-friendly message for this kind of common error.


Daehyok Shin

It's actually not that easy to provide the meaningful kind of error message 
you are asking for.  (Though it would be nice.)
Consider what happens in the case you give:

(1) The argument of plot() of evaluated, and has the value NULL
(2) plot() is called with a single argument, which is NULL

All the information available inside plot() is that its argument has the 
value NULL (without getting into meta programming).  However, it would be 
possible for plot(), or xy.coords(), to print a more meaningful error 
message like "called with NULL value for x".  This disadvantage of
doing
this is that if you do it everywhere, a considerable volume of the code 
becomes tests and error messages, which can make the code less readable and 
more prone to errors (because of the possibility that some of the tests are 
buggy themselves).  The weak type checking in the S language exacerbates 
these problems.  As it currently is, many functions are simple and concise, 
but provide very cryptic error messages when something goes wrong.  This is 
the tradeoff.

One might argue that x$z should cause an error, but it is a 
long-established behavior that the "$" operator returns NULL when the
list
element does not exist or is not uniquely identified (this might even be in 
the written definition of the S language).

It might be an interesting CS grad student project to build a system that 
matches cryptic error messages and stack traces against a library of common 
errors in order to provide less cryptic error messages.

-- Tony Plate

At Wednesday 01:07 PM 4/7/2004, Shin wrote:
>When I tried the following commands, I got a strange message.
>
>
> > x<-data.frame(y=c(1:10))
> > plot(x$z)
>Error in xy.coords(x, y, xlabel, ylabel, log) :
>         x and y lengths differ
>
>"The data frame, x, does not have a field named z."
>may be better user-friendly message for this kind of common error.
>
>
>Daehyok Shin
>
>______________________________________________
>R-help at stat.math.ethz.ch mailing list
>https://www.stat.math.ethz.ch/mailman/listinfo/r-help
>PLEASE do read the posting guide!
http://www.R-project.org/posting-guide.html

(Moved from r-help to r-devel).

On 07 Apr 2004 15:07:49 -0400, Shin <sdhyok@email.unc.edu> wrote :
>When I tried the following commands, I got a strange message.
>
>
>> x<-data.frame(y=c(1:10))
>> plot(x$z)
>Error in xy.coords(x, y, xlabel, ylabel, log) :
>        x and y lengths differ
>
>"The data frame, x, does not have a field named z."
>may be better user-friendly message for this kind of common error.
There are several places this could be fixed.  When you use x$z, the
code for $ could give an error message or a warning; instead it
returns NULL with no error or warning.  Changing this would probably
be dangerous:  I'd guess there's code out there that relies on getting
a NULL back from a construction like that.  But maybe we should change
that in 2.0?

Then plot(NULL) is called, which eventually results in the message you
saw.  That could be easily fixed:  plot.default could have 

if (is.null(x)) stop("x is NULL")

I can't think of a reason why this would cause trouble.  However, if
you had something like

plot(x$y, x$z)

the error wouldn't be detected.

Finally, the actual error message comes from a bug in the xy.coords
code: it has 

           y <- x
            x <- 1:length(x)

for the case where there is a NULL y supplied, and this is wrong:  it
should be x <- seq(along=x).  Making just this fix gives a fairly
inscrutable error message:

Error in plot.window(xlim, ylim, log, asp, ...) : 
        need finite xlim values
In addition: Warning messages: 
1: no finite arguments to min; returning Inf 
2: no finite arguments to max; returning -Inf 
3: no finite arguments to min; returning Inf 
4: no finite arguments to max; returning -Inf 

but this might be easier to figure out than the original one.

Duncan Murdoch

Gabor Grothendieck <ggrothendieck <at> myway.com> writes:
> 
> From: Shin, Daehyok <sdhyok <at> catchlab.org>
> > Con. Poor design for object-oriented programming, compared with
Python.
> 
> Have a look at oo.R package if you 
> want a more traditional oo approach.
As several people have pointed out, this package is not on CRAN and to
download it you need to get it from:

http://www.maths.lth.se/help/R/R.classes/

Also, look around on that site for manuals and
other information.