in reply to Generating a readline error

Like this? 

open NUL, '<', 'nul' or die $!;;
defined( $s = readline( NUL )) or die $!;;
[Died at (eval 9) line 1.

[download]

Or 

open O, '>', 'nul' or die $!;;
defined( $s = readline( O )) or die $!;;
Filehandle O opened only for output at (eval 11) line 1.

[download]
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP PCW

Replies are listed 'Best First'.
Re^2: Generating a readline error
by ikegami (Patriarch) on Jul 17, 2009 at 17:12 UTC
    You're misreporting eof as an error.
[reply]
Re^2: Generating a readline error
by ikegami (Patriarch) on Jul 17, 2009 at 17:54 UTC

    Thanks, the method used in the second snippet (added since my original reply) will be useful to me. It's even portable (using the appropriate device name)!

    It would be ideal if I had a means of generating an error after doing some valid reads, but I can make do without.

[reply]
      I guess you could read for awhile and then close the filehandle. It is possible to open 2 filehandles to same file. Close one and keep going with the other one after first bombs.

      My seek idea didn't work as seek past EOF is not an error (that's how to generate "sparse files"). I've tested that on Perl before (*nix and even XP) and it works fine and you just get EOF if you read something like that. Of course EOF is not an error. And of course a write past EOF is completely legal and produces no error.

      I've written device drivers that will pass back "known bad data" from say disk system. But that's a special thing and drivers,O/S,app have to know what's going on. That sort of thing is used in huge volume data applications where say 12 bits wrong won't matter in say a video image or a seismic data app.

      Still curious as to what kind of data recovery is possible in typ Perl app after "bad data" from an I/O device?

[reply]

        Still curious as to what kind of data recovery is possible in typ Perl app after "bad data" from an I/O device?

        Thinking you've reached the end of the file before you actually have can lead to incorrect error messages down the line or no error down the line when there should be one.

        I'm trying to fix readline's documentation. The snippet is wrong. A fix was provided for bleadperl (5.12-to-be), but it introduced an error while fixing none.

[reply]
[d/l]
Re^2: Generating a readline error
by JavaFan (Canon) on Jul 17, 2009 at 17:12 UTC
    That seems to die at the open, not the readline.
[reply]
      This will generate a "read error", but the only way I can see to do this is just the "filehandle not open" case. I don't how to easily create a "file system corrupted, data read error". I tried seeking past EOF and doing read but Perl does the right thing and returns EOF. Creating a data file that is intentionally corrupted is not something that I'm inclined to try on my main working machine!

      Its not clear to me why corrupted data case needs to be checked for, just let the program die if read can't get bytes. I mean what sort of error recovery would be feasible in that case by Perl? I think none. 

      #!/usr/bin/perl -w
use strict;

open (IN, "asdf"); #this fails but return code ignored

print while (<IN>); #readline() on closed filehandle 
                    #IN at C:\TEMP\ioerror.pl line 6.

      [download]
[reply]
[d/l]
        Well, I wouldn't like my web browser to crash if it encounters a read error on reading from a socket.

        While there are many cases I would let a program die if it encounters a read error, there are enough cases where the program should be robust enough to deal with read errors.

[reply]

In Section Seekers of Perl Wisdom