On Wednesday, November 05, 2003, at 01:49PM, Thomas R Wyant_III
<Thomas.R.Wyant-III@xxxxxxxxxxxxxx> wrote:
>
>Robert Atkinson wrote:
>
>> Remember, you're talking to someone who's used to programming in DCL, which
>> will almost always tell you when it encounters problems. Now I've begun using
>> this 'new' language Perl, I expect it to act similarly. When it doesn't, I
>> need to find out..
>If you want to care if _any_ operation succeeds, read up on it. The
>documentation should tell you what to expect.
Excellent advice, but often harder to follow than it should be. Think of
trying to explain to a VMS newbie why the RMS system services are not to be
found in the System Services Reference Manual, the CVT$ routines are in the
"RTL Library (LIB$)" even though they don't begin with LIB$, while the STR$
routines are in their own separate manual, and so on.
Finding out where the <> operator is documented took me longer than I care to
admit. You have to forget about the fact that it's something that implicitly
does reads on filehandles and remember that first and foremost it's an operator
and is documented in a manual entitled "Perl Operators and Precedence."
Specifically, look at
http://www.perldoc.com/perl5.8.0/pod/perlop.html#I-O-Operators
>The Perl <> input operator behaves pretty much like
>READ/END=label/ERROR=same_label in DCL. It's not hard to get an I/O loop to
>throw an error, though. Just code something like
>while (<>) {
># do something useful
>}
>die $! if $!;
>
>If you like, you can substitute $^E for $! in the "die." This gets you the
>VMS error rather than a generic one.
The reason things work the way Tom describes is that "while (<>)" is equivalent
to "while ($_ = <>)" and so the loop exits whenever $_ is undef. Then we check
Perl's wrapper around C's errno to see if there were any errors in the
operation we just completed.
Many, many Perl programs have this slightly wrong in that they don't check the
error status after the loop exit, and the assumption that EOF caused $_ to
become undefined isn't necessarily a good one. This isn't a Perl issue, per se
-- I see the equivalent thing all the time in DEC BASIC where a loop continues
as long as the error status from a READ is zero, which is ok as long as you
check right after the loop whether the error that caused the loop exit is EOF
or something else, a step that seems to get overlooked all too often in the
code I maintain.
Robert, let us know if this is helping. I think I now understand the import of
your question.
|
