Here are the quotes from the docs regarding PrintError
****************
The `AutoCommit' and `PrintError' attributes
for each connection default to "on".
(See the AutoCommit and PrintError
entries elsewhere in this document
for more information.) However, it is
strongly recommended that you
explicitly define `AutoCommit' rather
than rely on the default. Future
versions of the DBI may issue a warning
if `AutoCommit' is not explicitly defined.
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? Wouldn't $@ be
and empty string then?
Ilya Sterin
-----Original Message-----
From: Tim Bunce
To: Sterin, Ilya
Cc: 'Neil Lunn '; ''[EMAIL PROTECTED]' '
Sent: 05/08/2001 8:06 AM
Subject: Re: executing atomic transactions in DBI
On Tue, May 08, 2001 at 07:16:37AM -0600, Sterin, Ilya wrote:
> Thanks a lot, Neil. Finally a "make sense" answer. Thus, know I can
see
> why the script was not failing within eval (due to PrintError being
on). It
> is quoted in the docs and my fault for overlooking it. Definitelly
when we
> answer questions on this list we mostly tell people to turn their
RaiseError
> and PrintError on, though not explaining a clear difference between
> PrintError's involvement in the process. It should probaly be made
more
> clear that PrintError should not be turned on when using eval{} for
> transaction processing.
Somewhere the DBI docs say something to the effect that the behaviour
of PrintError when RaiseError is also set may change (to not print the
error) if the exception is triggered inside an eval block.
Tim.
> Ilya Sterin
>
> -----Original Message-----
> From: Neil Lunn
> To: Sterin, Ilya; '[EMAIL PROTECTED]'
> Sent: 05/07/2001 9:38 PM
> Subject: RE: executing atomic transactions in DBI
>
> Should this really be discussed off the list? Abolutely not.
>
> Ilya, your connect string in this script uses PrintError, as you
> knowingly
> mention yourself. I thought that this was made very clear in the docs.
>
> >From the fine Manual:
>
> ""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:
>
> This of course overides your calls to die, as you seem to imply as an
> intended behaivor in your message. Thus the calls to die are actually
> not
> needed. If you want different behaivour, remove PrintError => 1 from
the
> connection.
>
> If RaiseError is on, the script will die. If it is off the script will
> not
> die unless told to. If PrintError is on an error is trapped as a warn,
> otherise no warn is issued.
>
> Back to the start of this message. You reported to the list that you
> believed RaiseError was not always wroking. You posted your script,
and
> people can scrutinise and reply. That is the one great benefit of this
> list
> existing. We can all help each other.
>
> Also as Tim mentioned himself recently, we should be quoting the docs
> more
> often. This does help re-enforce their worth. If there is something
not
> clear in the documentation, it should also be discussed here. If there
> is a
> better way to do it, it will almost certainly end up in the
> documentation.
>
> Neil
>
>
> > -----Original Message-----
> > From: Sterin, Ilya [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, May 08, 2001 12:32 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: executing atomic transactions in DBI
> >
> >
> > Randal, we'll discuss off list since I totally agree that
> > this (rumor??) can
> > get out of hand. The script provided is supposed to fail
> > when the query
> > does not execute due to mispelled table name, but it rather
> > prints the error
> > message (as it suppost to) but then proceeds to print the
> > rest of the form.
> > The problem might also be in my script, server configuration,
> > etc..., so
> > before this gets out of hand, I'd rather this be investigated.
> >
> > Ilya Sterin
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > To: Sterin, Ilya
> > Cc: 'Stephen Clouse '; '[EMAIL PROTECTED] '; '[EMAIL PROTECTED] '
> > Sent: 05/07/2001 8:05 AM
> > Subject: Re: executing atomic transactions in DBI
> >
> > >>>>> "Ilya" == Sterin, Ilya <[EMAIL PROTECTED]> writes:
> >
> > Ilya> Not sure what you consider a rumor, I just simply stated
having
> > Ilya> a problem with it before and that in my experience I always
> > Ilya> check for return value, due to either the query failing and/or
> > Ilya> executing without failing, but still producing an unexpected
> > Ilya> result. By implying that the trasaction does not fail without
> > Ilya> checking for return, does not necessarily mean that there was
an
> > Ilya> SQL error, but rather the query produced an unexpected result.
> >
> > I think perhaps the problem was sloppy terminology. A RaiseError=1
> > block should prevent you from ever needing "|| die" after each call.
> > Let's call that a "DBI error".
> >
> > You seem to also be including the problem of a "domain error" where
> > something doesn't make sense, even though DBI has performed
perfectly
> > in getting the query to and from the database. No amount of "||
die"
> > will detect that, and therefore RaiseError=1 will be ineffective.
> >
> > So I think I was claiming that you were spreading FUD for claiming
> > that RaiseError=1 still needs "|| die" to trigger DBI errors. I'm
> > still waiting for a sample of that. The code you just posted does
not
> > have an eval {} block, so I doubt that you sent code that actually
> > shows the problem.
> >
> > But it appears that you also want a way of detecting domain errors
> > without having to check the length of the results. That's your
code,
> > your responsibility.
> >
> > Ilya> Sorry if I offended you in any way, since you decided to flame
> > Ilya> me, without reading the whole thread.
> >
> > You're not offending me, and I'm not flaming you. I'm just in rumor
> > control mode, since something like this can get out of hand.
> >
> > Please post some code that uses RaiseError=1, no "|| die" and an
eval
> > block, and yet still doesn't detect a DBI error, and that we can
> > verify. I'll bet this month's rent that either you can't, or that
> > we've found a bug in DBI that must be corrected.
> >
> > In any case, I'll stand by my claim that as I understand it, it's
> > intended and implemented that RaiseError=1 completely replaces the
> > need for adding "|| die" to detect DBI errors.
> >
> > --
> > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503
777
> > 0095
> > <[EMAIL PROTECTED]> <URL:http://www.stonehenge.com/merlyn/>
> > Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> > See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl
> > training!
> >
>
>
________________________________________________________________________
> __
> Please Note :
> Only the intended recipient is authorised to access or use this
e-mail.
> If
> you are not the intended recipient,
> please delete this e-mail and notify the sender immediately. The
> contents
> of this e-mail are the writer's
> opinion and are not necessarily endorsed by the Gunz Companies unless
> expressly stated.
>
> We use virus scanning software but exclude all liability for viruses
or
> similar in any attachment.
