readline error behavior

TheHobbit has asked for the wisdom of the Perl Monks concerning the following question:

Fellows monks,
I ask the enlightment of your wisdom about the following little problem.

As stated in perlfunc, readline(*HANDLE) returns undef at the end of file. The same obviously is true for the IO::File getline method.

I'm writing a class inheriting from IO::File which should read records from a formatted file. Obviously, the main thing to do, maybe the only one, is to redefine getline method.

My getline method looks like this:

sub getline {
  my $self = shift;
  my $line = $self->SUPER::getline() || return undef;
  
  #the _parse function check if the line is well formed and
  #returns a hash references filled with informations from 
  #the line. _parse() returns undef if there is a format
  #error in the line
  my $result = _parse($line);
  if (defined $result) {
    return $result;
  }
  else {
    #this is the tricky part...
    #what should I do?
  }
}
[download]

The problem is that I'm unable to decide what should my method do when the file is not actually at EOF but the current line is malformed. The options appears to be 'the same thing' as IO::File->getline(), but I can not found what this 'thing' is by reading the doc, or die-ing, which would oblige me to always wrap the calls to the method into a eval block.

What I'm asking from your wisdom is then:

what does getline return when there is an input error?
what should my getline do when it finds a format error?

Thanks for helping.

Leo TheHobbit

update: corrected some typos

Comment on readline error behavior Select or Download Code

Replies are listed 'Best First'.
Re: readline error behavior by Abigail-II (Bishop) on Nov 03, 2003 at 15:10 UTC
First of all, the line: `my $line = $self->SUPER::getline() \|\| return undef;` [download] has a problem; what if `$self->SUPER::getline()` returns "0"? Or ""? (which may happen if you don't subclass from IO::Handle directly, or if you are working with IO layers). As for what to return if the line is illformatted, you can do several things: Return 'undef' after setting $! or some other global variable, and leave it to the caller to inspect it. die with an appropriate message; it's up to the caller to use eval {} and catch an error. Return an overloaded object that is undefined in boolean context, but which can be inspected by the caller. You might return an overloaded object if your superclass returns undefined as well. Always return an object, whether on failure or success. It's up to the caller to inspect that object, and retrieve either the string, or the failure reason. Anyway, you need to return something special, which you document well, and it's up the caller to inspect your return value and handle appropriately. I probably would use the first suggestion. Abigail	[reply] [d/l] [select]
Re: readline error behavior by welchavw (Pilgrim) on Nov 03, 2003 at 16:46 UTC
Leo, The docs do eventually indicate that `getline` behaves as readline. Some of the relevant documentation regarding `readline` follows (you should definitely read all the docs as I'm not going to touch on other aspects of the interface, such as context-sensitive-return requirements). If readline encounters an operating system error, $! will be set with the corresponding error message. Thus, to overload `getline`, I believe you should apply the same semantics. ,welchavw	[reply] [d/l] [select]
Re: readline error behavior by zoccav (Sexton) on Nov 03, 2003 at 19:46 UTC
Hi Leo, IMHO you are mixing distinct tasks in file parsing. File reading. Scanning (or call it tokenizing.) Parsing. At least, that's how Aho, Sethi and Ullman was sumarized to me. For the scanning I would write a class that parses output from a handle and returns tokens or raises exceptions. In fact I am working on a general purpose tokenizer/token package to deal with such cases. The code is one small part of a larger project I do so I haven't made it public (yet.) Tell me if you really want a preview of the package. I did similar work in this module. Vincenzo	[reply]


more useful options
	PerlMonks