develooper Front page | perl.perl5.porters | Postings from June 2009

Re: improving $! usability

Thread Previous | Thread Next
From:
Michael G Schwern
Date:
June 21, 2009 04:23
Subject:
Re: improving $! usability
Message ID:
4A3E1805.20801@pobox.com
Craig A. Berry wrote:
> On Sat, Jun 20, 2009 at 2:30 PM, Michael G Schwern<schwern@pobox.com> wrote:
>> Stepan Kasal wrote:
> 
>>> Perhaps the perl interpreter should make sure that eof is unset if an
>>> error appears, so that we can look at it.
> 
> If you already know that you've hit end-of-file, why does it matter
> that subsequent attempts to perform I/O on that stream generate
> errors?  Likely I'm misunderstanding -- I just don't know how.
> 
>>> Or should we rather introduce ferror to perl?
>> It might be nice to have errors attached to filehandles.  That pushes use more
>> towards making real IO objects.
> 
> You mean like:
> 
> =item B<PerlIO_error(f)>
> 
> This corresponds to ferror().  Returns a true/false indication of
> whether there has been an IO error on the handle.
> 
> from perlapio.pod?
>
>> But it only helps when there's a filehandle.  unlink(), chdir(), mkdir(),
>> etc... don't have a filehandle.
> 
> But these are pretty atomic and don't involve PerlIO as far as I know.
>  Handling errors from these is really a different type of problem from
> handling errors while reading from or writing to a stream.

Perhaps at the implementation level, but not at the user level.  As a Perl
programmer I don't care what's using PerlIO and what's not.

What I was thinking was something like:

    open my $fh, "<", $file or die $fh->error;
    while(<$fh>) {
        print;
    }
    die $fh->error if $fh->error;

After each IO operation Perl would check ferror() and, if set, attach errno to
the $fh.  Then error() would return errno for just that filehandle.  Then we'd
have a more reliable way to check for error on a particular filehandle.

IO::Handle already partially does this.  It has error() but it just returns
ferror(), it doesn't store nor return errno so there's no guarantee errno is
valid for this error.


>>> Better yet, wouldn't it be possible to make sure that $! is not set
>>> by a successful io operation?
>>> Either It could be cleared after every successful io operation.
>>> (Or the value could be saved before the io call and then restored if
>>> the io was successful, so that backward compatibility with broken
>>> perl code is maintained.)
> 
> I think the difficulty here is defining what is or is not an "io
> operation."  Percolating data through the PerlIO layers may or may not
> trigger various system calls that may or may not set errno.  Scaling
> back the number of cases where PerlIO sets errno is a start, and we've
> done that.  Blindly clearing errors seems a little dangerous to me.
> 
> I'm sure there's more work to be done here.  It's not my particular
> itch to scratch.

This might be something autodie can do.  Hmm.


-- 
31. Not allowed to let sock puppets take responsibility for any of my
    actions.
    -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
           http://skippyslist.com/list/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About