Hardy, Thanks for the info and for looking at it :-)
In this instance, I really do want to exit the script immediately. The script is
executed by a job scheduler (CA Unicenter) at various times, it's purpose is to
provide automation of a batch process. If it returns 0, then UniCenter can schedule
the next job in the sequence; if not the Unicenter console displays the exit code from
the script and someone gets called to resolve it. I use exit codes 240-255 to
indicate infrastructure/environmental problems, 1-239 are user application problems.
Thanks for the info, though...I'm still learning Perl and I haven't used evals yet,
the info you provided. made me realize where/why I might want to use it. Getting the
digest version of this mail list and the win32 mail list has been very educational...a
big thanks to all who contribute!!
Paula
----Original Message-----
From: Hardy Merrill [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 27, 2002 9:26 AM
To: Capacio, Paula J
Subject: Re: RESOLVED: Does failed PREPARE close db handle?
Paula, the one thing I noticed about your error processing
subroutine - the one that you wanted to return "243"(I think?) - was
that it was using "exit" instead of "return". "exit" will actually
exit the script immediately, but I don't think you want to do that,
do you? Usually you'll want your error subroutine to "return" the
proper value to it's caller.
Here's the "perldoc -f exit" section:
exit EXPR
Evaluates EXPR and exits immediately with that
value. Example:
$ans = <STDIN>;
exit 0 if $ans =~ /^[Xx]/;
See also "die". If EXPR is omitted, exits with
"0" status. The only universally recognized val
ues for EXPR are "0" for success and "1" for
error; other values are subject to interpretation
depending on the environment in which the Perl
program is running. For example, exiting 69
(EX_UNAVAILABLE) from a sendmail incoming-mail
filter will cause the mailer to return the item
undelivered, but that's not true everywhere.
Don't use "exit" to abort a subroutine if there's
any chance that someone might want to trap what
ever error happened. Use "die" instead, which can
be trapped by an "eval".
The exit() function does not always exit immedi
ately. It calls any defined "END" routines first,
but these "END" routines may not themselves abort
the exit. Likewise any object destructors that
need to be called are called before the real exit.
If this is a problem, you can call
"POSIX:_exit($status)" to avoid END and destructor
processing. See the perlmod manpage for details.
That was the only thing I noticed - I didn't even see the "$dbConn"
string issue that you found - good catch!
HTH.
Hardy Merrill
Senior Software Engineer
Red Hat, Inc.
[EMAIL PROTECTED]
"Capacio, Paula J" wrote:
>
> On my way home last night I realized I could strip out more of my script and answer
>the question myself. I proved that a failed prepare does NOT close the db handle.
>The problem was in how I was passing the db handle to my error subroutine.
> I had coded...
> my $mColsth = $dbConn->prepare( $mCols ) or
>processError("PrepareFailed","$mCols","$dbConn");
> which (I believe) was treating the object reference as a string.
> I changed it to....
> my $mColsth = $dbConn->prepare( $mCols ) or
>processError("PrepareFailed","$mCols",$dbConn);
> It works as expected now. Sorry to have bothered you.
> Paula
