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..
> - Why?
> - How do I make it act correctly, i.e. trap errors?
> - What other problems am I going to encounter, because Perl doesn't
report errors?
> These may seem simplistic or even stupid questions if your used to Perl,
but
> for a novice, these are the fundamentals for learning how a language
works.
> Until I know the 'gotchas', I cannot trust what I'm writing and the
results I
> get out.
Actually, I have programmed in DCL for a long time, and one of my chief
gripes is that it frequently does _not_ tell you when it encounters
problems. This is not to differ with you, or to slam DCL. What it really
tells you is my expectations. Before I programmed in (among other things)
DCL, I programmed in (among other things), the RSX Indirect Command
Language. This had "atomic" directives to query the user for a string, a
number, or a boolean; the reply was checked for validity and the user was
re-promoted until he or she got it right - all transparantly to the user.
DCL has nothing like this, and the number of lines consumed by the
VMSINSTAL procedure to mimic this behaviour is not to be believed. And VMS
was supposed to be an improvement?
The moral of this mini war story is that every programming environment has
a corresponding mindset, which one needs to get into. DCL's mindset, in
most cases (though not mine), is that it wants to detect errors and die
when it sees them. Perl tends to assume that if you want to know if there
was an error, you will ask it, and it tends to die only of there's no good
way for it to continue execution.
What touched off both the war story and the moralizing was the phrase "How
do I get it to act correctly, i.e. trap errors?" Perl _does_ act correctly,
to the best of my knowledge. That is, it behaves as documented. It simply
doen't behave like DCL. If DCL is what you want, you will be dissatisfied
with Perl. Just as you will be dissatisfied with DCL if what you want is
Perl.
OK. Now that I have that off my chest, maybe I can get down to something
that's actually useful to you.
Perl does _not_ throw an exception on an I/O error the way DCL does.
Neither does it throw an exception when a spawned executable returns error
status. These are the major things I can come up with at the moment, though
I'm sure they're not the only ones. Because this is Perl, There's More
Than One Way To Do It, right down to overriding core Perl functions to make
them behave the way you want. But my best advice for dealing with these is:
"use warnings;" at the top of your scripts. This will help in at least some
cases.
"use strict;" is generally recommended, but it may take some getting used
to for a DCL programmer, since you now generally need to "predeclare" your
variables in some way, either with "my" or by "use vars".
If you want to care if _any_ operation succeeds, read up on it. The
documentation should tell you what to expect. Even without a core function
override there are things you can do. For example:
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.
System commands get run various ways in Perl. My favorite (versus the DCL
functionality) is `command`, which returns the command's output, saving you
the trouble of running the command /OUT= (or assigning SYS$OUTPUT to a file
if the command doesn't support /OUT=), and then opening, reading, and
closing the file. If you care whether your spawned command worked, consult
$?. If you're doing this a lot, write a subroutine to do it for you.
While I'm on the subject of spawned commands, I'd like to point out a thing
I still fall over: dollar signs. I don't know how many times I have spawned
a command involving some standard VMS logical (e.g. SYS$COMMAND) and had it
rejected because Perl regarded it as interpolation of variable $COMMAND.
This again is the way Perl works. "use strict;" won't prevent the
substitution, but it will turn your execution errors into Perl compile-time
errors.
Guess I have to get back to real work now. About time, too.
Tom Wyant
This communication is for use by the intended recipient and contains
information that may be privileged, confidential or copyrighted under
applicable law. If you are not the intended recipient, you are hereby
formally notified that any use, copying or distribution of this e-mail,
in whole or in part, is strictly prohibited. Please notify the sender
by return e-mail and delete this e-mail from your system. Unless
explicitly and conspicuously designated as "E-Contract Intended",
this e-mail does not constitute a contract offer, a contract amendment,
or an acceptance of a contract offer. This e-mail does not constitute
a consent to the use of sender's contact information for direct marketing
purposes or for transfers of data to third parties.
Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean
http://www.DuPont.com/corp/email_disclaimer.html
