This queue is for tickets about the Text-CSV_XS CPAN distribution.

Report information
The Basics
Id:
27424
Status:
resolved
Priority:
Low/Low
Queue:

People
Owner:
HMBRAND [...] cpan.org
Requestors:
ianburrell [...] gmail.com
Cc:
AdminCc:

BugTracker
Severity:
(no value)
Broken in:
0.26
Fixed in:
0.30



Subject: Regression in interface of getline().
The change in 0.26 for getline() to return undef instead of empty array for EOF is a serious regression. Our code that displayed errors now does an infinite loop. The naive example in the code doesn't handle errors. The problem is that there is no documented way to determine the difference between an error and EOF. With a parse error, it is possible to continue parsing the rest of the file while EOF needs to exit the loop. Even if it isn't possible to continue parsing, we want to display the error. It should be made clear in the documentation that getline() returns undef of EOF and on error. If there is a way to distinguish between parse errors, IO errors, and EOF (undef error_input, status), then it should be mentioned. I think eof($io) will work.
Subject: Re: [rt.cpan.org #27424] Regression in interface of getline().
Date: Mon, 4 Jun 2007 20:37:06 +0000
To: bug-Text-CSV_XS@rt.cpan.org
From: "H.Merijn Brand" <h.m.brand@xs4all.nl>
On Mon, 04 Jun 2007 15:11:47 -0400, "ianburrell@gmail.com via RT" <bug-Text-CSV_XS@rt.cpan.org> wrote:
Show quoted text
> > Mon Jun 04 15:11:25 2007: Request 27424 was acted upon. > Transaction: Ticket created by ianburrell@gmail.com > Queue: Text-CSV_XS > Subject: Regression in interface of getline(). > Broken in: 0.26 > Severity: (no value) > Owner: Nobody > Requestors: ianburrell@gmail.com > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=27424 > > > > The change in 0.26 for getline () to return undef instead of empty array > for EOF is a serious regression.
IIRC that was how it was documented, but didn't work. See http://rt.cpan.org/Ticket/Display.html?id=21530
Show quoted text
> Our code that displayed errors now does an infinite loop. > The naive example in the code doesn't handle errors. > > The problem is that there is no documented way to determine the > difference between an error and EOF. With a parse error, it is possible > to continue parsing the rest of the file while EOF needs to exit the > loop. Even if it isn't possible to continue parsing, we want to display > the error. > > It should be made clear in the documentation that getline () returns > undef of EOF and on error. If there is a way to distinguish between > parse errors, IO errors, and EOF (undef error_input, status), then it > should be mentioned. I think eof ($io) will work.
I am thinking an EOF state that can be inquired with $csv->eof (); That would be better than eof ($io) I think. In 0.28, you can read my release plan: --8<--- =head1 Release plan =over 2 =item 0.29 - croak / carp - error cause - return undef -->8--- So your remarks fall into this category, and if you feel the need, I can release quite soon. -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11, & 11.23, SuSE 10.0 & 10.2, AIX 4.3 & 5.2, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
0.30 now has a lot of more advanced error diagnostics error_diag $csv->error_diag (); $error_code = 0 + $csv->error_diag (); $error_str = "" . $csv->error_diag (); ($cde, $str) = $csv->error_diag (); If (and only if) an error occured, this function returns the diagnostics of that error. If called in void context, it will print the internal error code and the associated error message to STDERR. If called in list context, it will return the error code and the error message in that order. If called in scalar context, it will return the diagnostics in a single scalar, a-la $!. It will contain the error code in numeric context, and the diagnostics message in string context. eof $eof = $csv->eof (); If "parse ()" or "getline ()" was used with an IO stream, this method will return true (1) if the last call hit end of file, otherwise it will return false (''). This is useful to see the difference between a failure and end of file.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.