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.
