in reply to Re: Generating a readline error
in thread Generating a readline error

That seems to die at the open, not the readline.

Replies are listed 'Best First'.
Re^3: Generating a readline error
by Marshall (Canon) on Jul 17, 2009 at 18:04 UTC
    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]
        This sort of thing over not so reliable communication links is different than what I understood the question to be. I was watching one of my LWP programs yesterday and it bombed 4x in a row because the other site wasn't up. Things got sorted out and it worked. The application level stuff reconnects and tries again.

        Here the question appeared to be me to formulated in terms of a disk file access. Maybe I got the wrong impression. I've worked on a number of very impressive IBM disk systems and I've never seen an application "retry" work because we give it the "full court press" when we know the data is important.

        Anyway there is a big difference between: communication failed, bad packet, unable to connect, unable to authenticate, and "I've read some data but I know that is wrong, but before I use error correcting codes, I'm going to the best most consistent data that I can".

        Anyway a sophisticated disk system has already done a complex series of 200 attempts before it says "I can't read the data". The IP communication layer is not that robust.

[reply]

In Section Seekers of Perl Wisdom