First off, I had no idea it existed until I started going through a dbi
tutorial. The idea is you don't have to litter your code with "or
die..." statements.
Is it good practice to use this or is an explicit "or die..." better
because you can "see" there is error trapping?
Robert
> From: Robert Hicks [mailto:sigzero@gmail.com]
> Sent: Tuesday, August 14, 2007 01:16 PM
> So I should still "or die..." even if I set ShowErrorStatement? I ask, =
> because if true, then I would like to let the author of the paper I am =
> reading know to make corrections if needed.
To oversimplify somewhat:
* PrintError prints an error message whenever there is an error.
* RaiseError does the same as PrintError and also dies.
* ShowErrorStatement shows the SQL statement associated with an error if =
either PrintError or RaiseError is true but does nothing otherwise.
ShowErrorStatement only sets the level of verbosity of the messages shown=
by PrintError and RaiseError, it does not specify whether the message is=
shown in the first place or whether the error causes the program to die.=
So no, ShowErrorStatement has nothing to do with whether or not you spr=
inkle your code with "or die" statements.
RaiseError is the one that dies on error. If it is set then you do *not*=
need to explicitly "or die". If it is not set, and you do not use "or di=
e" your program will keep running even after it encounters errors.
Styles vary, my personal preference is to set RaiseError to true in the c=
onnect statement and omit "or die" in the rest of the code.
--
Jeff
Oh, one addendum: the ability to use RaiseError instead of "or die" state=
ments applies *only* to DBI-related errors. It means you can omit "or di=
e" on DBI methods such as prepare() and execute(). For methods and funct=
ions that are not DBI, you'll need to use "or die" if you want to trap ot=
her kinds of perl errors in your code.
--
Jeff
> -----Original Message-----
> From: jeff@vpservices.com [mailto:jeff@vpservices.com]
> Sent: Tuesday, August 14, 2007 04:01 PM
> To: sigzero@gmail.com, dbi-users@perl.org
> Subject: Re: ShowErrorStatement
>
>
> > From: Robert Hicks [mailto:sigzero@gmail.com]
> > Sent: Tuesday, August 14, 2007 01:16 PM
>
> > So I should still "or die..." even if I set ShowErrorStatement? I ask=
,
> > because if true, then I would like to let the author of the paper I a=
m
> > reading know to make corrections if needed.
>
> To oversimplify somewhat:
>
> * PrintError prints an error message whenever there is an error.
>
> * RaiseError does the same as PrintError and also dies.
>
> * ShowErrorStatement shows the SQL statement associated with an error i=
f either PrintError or RaiseError is true but does nothing otherwise.
>
> ShowErrorStatement only sets the level of verbosity of the messages sho=
wn by PrintError and RaiseError, it does not specify whether the message =
is shown in the first place or whether the error causes the program to di=
e. So no, ShowErrorStatement has nothing to do with whether or not you s=
prinkle your code with "or die" statements.
>
> RaiseError is the one that dies on error. If it is set then you do *no=
t* need to explicitly "or die". If it is not set, and you do not use "or =
die" your program will keep running even after it encounters errors.
>
> Styles vary, my personal preference is to set RaiseError to true in the=
connect statement and omit "or die" in the rest of the code.
>
> --
> Jeff
>
>
>
>
>
On Tue, 14 Aug 2007 16:01:21 +0000, jeff@vpservices.com wrote:
>To oversimplify somewhat:
>
>* PrintError prints an error message whenever there is an error.
>
>* RaiseError does the same as PrintError and also dies.
I've always wondered, and now seems a good time to ask as any: why are
PrintError and RaiseError not mutually exclusive? It seems silly to have
both on at the same time, essentially printing the error message twice.
(Yes I've tested it with a fairly recent version of DBI: 1.52).
--
Bart.
On Sat, Aug 18, 2007 at 12:02:47PM +0200, Bart Lateur wrote:
> On Tue, 14 Aug 2007 16:01:21 +0000, jeff@vpservices.com wrote:
>
> >To oversimplify somewhat:
> >
> >* PrintError prints an error message whenever there is an error.
> >
> >* RaiseError does the same as PrintError and also dies.
>
> I've always wondered, and now seems a good time to ask as any: why are
> PrintError and RaiseError not mutually exclusive? It seems silly to have
> both on at the same time, essentially printing the error message twice.
> (Yes I've tested it with a fairly recent version of DBI: 1.52).
The exception may be caught by an eval { }.
Using PrintError you'd still get a warning.
Tim.