Re: Minor knit pick: errors

[Ethan A M. <sf...@us...>]

On Wednesday, 17 September, 2014 21:07:58 pl...@pi... wrote:
> On 09/17/14 20:15, Ethan A Merritt wrote:
> >
> > On Wednesday, 17 September, 2014 11:33:40 pl...@pi... wrote:
> >> Hi,
> >>
> >> it is not very helpful that gnuplot  does not distinguish between
> >> non-existent files and files it cannot parse for plotting.
> >>
> >>    warning: Skipping unreadable file ......
> >>
> >> Whenever I get this I have to try to work out whether there is a typo or
> >> come other error in the path specifier or whether there are some header
> >> lines or other formatting problems with data in a file  that it is able
> >> to find.
> >
> > Could you be more specific?
> > I get several different errors.  It is true that "unreadable" can be misleading
> > for a file that doesn't exist at all, but in the case of formatting problems
> > in the file "Bad data on line X" seems clear enough.
> >
> > gnuplot> plot 'notthere.dat'
> >           warning: Skipping unreadable file "notthere.dat"
> >           No data in plot
> >
> > gnuplot> plot 'readprotected.dat'
> >           warning: Skipping unreadable file "readprotected.dat"
> >           No data in plot
> >
> > gnuplot> plot 'emptyfile.dat'
> >           warning: Skipping data file with no valid points
> >                               ^
> >           x range is invalid
> >
> > gnuplot> plot '/bin/true'
> >                ^
> >           Bad data on line 1 of file /bin/true
> >
> >
> >> since these must be quite different error conditions as far as where and
> >> how they are trapped in the code, some distinction would be very helpful
> >> in saving time finding the problem.
> >>
> >>
> >> Regards, Peter.
> >
> >
> 
> Thanks you are correct. The data errors are clear enough.
> 
> What causes confusion is that missing files are reported like the fiile 
> has been found but  there's a problem reading it.
> 
> Clearly "unreadable" needs to be changed to something more explicit if 
> it's a file not found error., perhaps also with something more explicit 
> if it is a read access problem since "unreadable" sounds like it has 
> been opened but can not be read as data.
> 
> My guess is that someone historically has got an error with an 'open 
> with read access' command  and tried to use a generic error msg that 
> covers all bases.

It's more complicated than that, since it can also fail if your
"set loadpath" string is bad, or the path length becomes too long,
or a network access times out, etc, etc.

Furthermore the routine loadpath_fopen() tries to find the file
in multiple places, and may fail several times with various errors
before either succeeding or giving up.  So you can't just echo back
every error that occurs on an fopen()  command.

I'm not opposed to more explicit error messages if you want to work
on a patch to implement it, but it will take more than just adding 
int_warn(NO_CARET, strerrorr(errno)) at some single place.

Nevertheless I agree that the error message might more accurately say
"Cannot find or open file" rather than "unreadable file".

	Ethan

> While this is technically correct, it is the not the most helpful 
> solution in a situation where it is imperative to find out where the 
> problem lies to fix it.
> 
> 
> .Peter.
>