In the docs shouldn't this be changed...
***
If `PrintError' is also on, then the
`PrintError' is done before the `RaiseError'
***
to
***
If `PrintError' is also on, then the
`PrintError' is done before the `RaiseError'
though 'RaiseError' will override 'PrintError'
and the error will be printed as die() rather than
warn().
***
Or something like that...
Ilya Sterin
-----Original Message-----
From: Tim Bunce
To: Sterin, Ilya
Cc: 'Tim Bunce '; ''Neil Lunn ' '; '''[EMAIL PROTECTED]' ' '
Sent: 05/08/2001 10:40 AM
Subject: Re: executing atomic transactions in DBI
On Tue, May 08, 2001 at 08:26:43AM -0600, Sterin, Ilya wrote:
> Here are the quotes from the docs regarding PrintError
>
> ****************
>
> PrintError' (boolean, inherited)
> This attribute can be used to force
> errors to generate warnings (using `warn')
> in addition to returning error codes
> in the normal way. When set "on", any
> method which results in an error occuring
> will cause the DBI to effectively do a
> `warn("$class $method failed: $DBI::errstr")'
> where `$class' is the driver class and
> `$method' is the name of the method which
> failed. E.g.,
>
> `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. E.g.,
>
> DBD::Oracle::db prepare failed: ...
> error text here ...
>
> If `PrintError' is also on, then the
> `PrintError' is done before the `RaiseError'
> unless no `__DIE__' handler has been
> defined, in which case `PrintError' is
> skipped since the `die' will print the message.
>
> ************
>
> I guess my question is does this imply that PrintError in a way
disables
> RaiseError or somehow effects it's use. If yes, by PrintError being
turned
> on by default it should then be explicitelly turned off and RaiseError
> turned on before using eval{} for transaction processing. Since eval
traps
> the die() calls, my understanding from
>
> ****
> If `PrintError' is also on, then the
> `PrintError' is done before the `RaiseError'
> unless no `__DIE__' handler has been
> defined, in which case `PrintError' is
> skipped since the `die' will print the message.
> ****
>
> That PrintError will actually print the error message and then
RaiseError is
> called, which will call die() but without the error message?
They'd both have the same message. Here's the C code:
/* PrintError = report errors via warn() */
if (DBIc_has(imp_xxh, DBIcf_PrintError)) {
/* if both PrintError and RaiseError are true */
/* we do both unless there's no __DIE__ hook */
/* XXX we should also check if we're inside an eval */
if (!raise_error || (diehook && SvOK(diehook)))
warn("%s", SvPV(msg,lna));
}
/* RaiseError = report errors via croak() */
if (raise_error)
croak("%s", SvPV(msg,lna));
Note the XXX. The principle is that there's no point in doing the
warn() if the croak (ie die) is going to print the same message.
But generally people turing on RaiseError will turn off PrintError.
The
