Michael A Chase [EMAIL PROTECTED] wrote:
> On Tue, 01 Jul 2003 16:12:09 -0600 Ian Harisay <[EMAIL PROTECTED]>
> wrote:
>
> > Doing the redirect can be a bit clunky. If you want to be more
> > precise with how you handle these errors, add this $attr to your
> > connect statement.
> >
> > my $attr = { PrintError => 0, RaiseError => 1, AutoCommit => 0 };
> > my $dbh = DBI->connect( @{$login}, $attr )
> > or die "Can't connect to Oracle database: $DBI::errstr\n";
> >
> > then when an error occurs it will not print to STDERR. Rather it
> > can be read thru $dbh->errstr.
>
> Did you mean 'RaiseError => 0'? With 'RaiseError => 1', connect() never
> returns if an error occurs. In either case (RaiseError or die), the
I'm not sure I understand. According to the DBI perldocs
on RaiseError:
"RaiseError" (boolean, inherited)
This attribute can be used to force errors to raise exceptions
rather than simply return error codes in the normal way. It is
"off" by default. When set "on", any method which results in an
error will cause the DBI to effectively do a "die("$class $method
failed: $DBI::errstr")", where $class is the driver class and
$method is the name of the method that failed.
My impression is that RaiseError => 1 causes a "die" to occur
on any DBI error. Not true with RaiseError on connect? I'm
probably just missing something - it's early ;-)
I've typically used RaiseError => 1 and surrounded connect with
an eval - not sure what the difference is between that and
having RaiseError cause a die on the connect. What am I
missing?
> output goes to STDERR.
>
> When I need to force STDERR to another place, I use open().
> Note the autoflush() as well, otherwise the order of output lines
> going to a file may be incorrect since STDERR is not buffered.
>
> open( LOG, ">> $file" );
> autoflush LOG 1;
> open( STDERR, ">&=" . fileno( LOG ) );
Excellent - never seen it done this way before.
--
Hardy Merrill
Red Hat, Inc.
