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

Re: improving $! usability

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
June 21, 2009 04:36
Subject:
Re: improving $! usability
Message ID:
20090621133602.133572a2@pc09.procura.nl
On Sun, 21 Jun 2009 07:22:45 -0400, Michael G Schwern
<schwern@pobox.com> wrote:

> 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;

this is *very* counter-intuitive.
After a fail, I expect $fh to be false. How do I call a method on an
undefined value?

>     while (<$fh>) {
>         print;
>         }
>     die $fh->error if $fh->error;

Here, I like it

> 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.

-- 
H.Merijn Brand  http://tux.nl      Perl Monger  http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/

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