Front page | perl.perl5.porters |
Postings from February 2013
On 2013-02-17 20:31, Tom Christiansen wrote:
>> On 2013-02-17 02:30, Tom Christiansen wrote:
>>> However, if hitting EOF is an expected and normal event, you
>>> would not to exit just because you ran out of input. Instead,
>>> you probably just want to exit an input loop. Immediately
>>> afterwards you can then test to see if there was an actual
>>> error that caused the loop to terminate, and act accordingly:
>>>
>>> while (<$handle>) {
>>> # do something with data in $_
>>> }
>>> if ($!) {
>>> die "unexpected error while reading from $filename: $!";
>>> }
>
>> I don't like to show a test of such a global.
>
> Which one is that? You have no choice.
>
>> Only if you already know something went wrong, then you can use the
>> global's value(s).
>
> Actually, you know something went wrong. You got undef back from
> readline. The question is whether there was an error or whether
> it was eof. The one and only way to know that is to check $! as
> the very very very next thing after the failed call.
But it shouldn't be the one and only way, because it is a global, right?
I don't see how you can rely on nothing happening between a failed
(method) call and a check of a global. Even if it currently works (most
of the time), it is not sustainable. So $fh->error() needs to work properly.
Result-status and error-status (and further, error-history) should not
be mixed. They need their own channel.
>> Maybe test $handle->error?
>
> Yesterday I showed that not to work in all cases.
Yes, and I only read that later. That badly needs fixing.
Seriously, in documentation I rather see $fh->error() used as if it does
work properly. (with remarks about known issues)
--
Ruud
Thread Previous
|
Thread Next