Solved!
Today's award goes out to Charles Jardine!
By upgrading from perl-DBI-1.40-8.x86_64.rpm to
perl-DBI-1.607-1.el5.rf.x86_64.rpm, and adding
$dbHandle->{RaiseError} = 1;
$dbHandle->{PrintError} = 0;
the eval block exception handling mechanism is working
for DBI faults. Additionally, the DBI->trace()
flow-of-execution/output is "back to normal."
Many thanks to Charles Jardine, Jenda Krynicky, and
Ian Harisay for taking the time to consider my problem
and post their thoughts.
KFW
At 12:45 PM 8/26/2009, Charles Jardine wrote:
On 25/08/09 18:53, Kevin Webb wrote:
Greetings!
My eval blocks are not catching exceptions when executed on RH el5
installations.
[snip]
This used to work on ELsmp (2.6.9-78.0.17.ELsmp) with DBI-1.50.tar.gz,
and DBD-Oracle-1.17.tar.gz using default values for RaiseError
and PrintError.
I am now on an RH el5 (2.6.18-53.1.14.el5) installation using
perl-DBI-1.40-8.x86_64.rpm
and perl-DBD-Oracle-1.19-1.el5.x86_64.rpm.
[snip]
and all that happens is a bailout on $stmnt->execute() with
the word 'Aborted' dumped to stderr ($stmnt->execute() does not return
a value).
I think you may be misinterpreting the one-word message 'Aborted'.
The shell would write this message if your program had terminated
with an abort signal (i.e. SIGABRT). An abort signal can result
from a call of the standard C library function abort() within
the program.
I have doenloaded DBI-1.40 and DBD-Oracle-1,19 from CPAN and
searched both distributions for the word 'Aborted', calls of
abort(), and mentions of 'ABRT'. I have found nothing.
I am suspicious of the package perl-DBI-1.40-8.x86_64.rpm. Where
did it come from? Why is the version so old? DBD-1.40 dates
back to January 2005.
--
Charles Jardine - Computing Service, University of Cambridge
[email protected] Tel: +44 1223 334506, Fax: +44 1223 334679
