RE: [PHP] Best practice for if (!$stmt-execute())
-Original Message-
From: Rico Secada [mailto:coolz...@it.dk]
Sent: Sunday, October 24, 2010 9:06 PM
To: php-general@lists.php.net
Subject: [PHP] Best practice for if (!$stmt-execute())
Hi.
I have been doing like this:
if (!$stmt-execute()) {
return false;
} else {
... some code
return true;
OR
return $foo; // Some int, string, whatever.
}
I am thinking about changing the return false with a:
if (!$stmt-execute()) {
die(DB_ERROR);
This way making sure that every single db execute gets a valid check and
at
the same time return some kind of valuable db error to the user and end
the
script.
How do you deal with db execution checks?
Thanks in advance!
Best regards.
Rico.
Rico,
Shouldn't you consider this as what happens, while in production, should
the script fails?, whether its DB related or not. In that case, how would
you want to handle the error? Do you, or the system admin, want to be
notified one way or another of the failure? Do want to implement a backup
in case that failure happens as an 'automatic recovery' mechanism? As a
system/network admin, I go by 3 guidelines:
1) Prevent failure as much as I can (either system hardware, software
applications, hacks/exploits/vulnerabilities, etc.).
2) In the event that 1 fails, what's the recovery process? How fast can I
recover from it?
3) If 2 fails, then there's something wrong with the whole process, which I
need to expand my knowledge skillset.
In my past experiences, I haven't yet got to stage 2 because there
precautions you can take to detect when a failure is about to happen so that
stage 2 will never happens. What you need to consider is how important is
this? Is it mission critical?
Regards,
Tommy
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Best practice for if (!$stmt-execute())
On Mon, 25 Oct 2010 00:26:23 -0700
Tommy Pham tommy...@gmail.com wrote:
-Original Message-
From: Rico Secada [mailto:coolz...@it.dk]
Sent: Sunday, October 24, 2010 9:06 PM
To: php-general@lists.php.net
Subject: [PHP] Best practice for if (!$stmt-execute())
Hi.
I have been doing like this:
if (!$stmt-execute()) {
return false;
} else {
... some code
return true;
OR
return $foo; // Some int, string, whatever.
}
I am thinking about changing the return false with a:
if (!$stmt-execute()) {
die(DB_ERROR);
This way making sure that every single db execute gets a valid
check and
at
the same time return some kind of valuable db error to the user and
end
the
script.
How do you deal with db execution checks?
Thanks in advance!
Best regards.
Rico.
Rico,
Shouldn't you consider this as what happens, while in production,
should the script fails?, whether its DB related or not. In that
case, how would you want to handle the error? Do you, or the system
admin, want to be notified one way or another of the failure? Do
want to implement a backup in case that failure happens as an
'automatic recovery' mechanism? As a system/network admin, I go by 3
guidelines:
1) Prevent failure as much as I can (either system hardware, software
applications, hacks/exploits/vulnerabilities, etc.).
2) In the event that 1 fails, what's the recovery process? How fast
can I recover from it?
3) If 2 fails, then there's something wrong with the whole process,
which I need to expand my knowledge skillset.
In my past experiences, I haven't yet got to stage 2 because there
precautions you can take to detect when a failure is about to happen
so that stage 2 will never happens. What you need to consider is how
important is this? Is it mission critical?
Regards,
Tommy
Thank you for some very important thoughts! Creating an extended error
handling function seems appropriate.
Regards,
Rico
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Best practice for if (!$stmt-execute())
On Mon, Oct 25, 2010 at 06:06:24AM +0200, Rico Secada wrote:
Hi.
I have been doing like this:
if (!$stmt-execute()) {
return false;
} else {
... some code
return true;
OR
return $foo; // Some int, string, whatever.
}
I am thinking about changing the return false with a:
if (!$stmt-execute()) {
die(DB_ERROR);
This way making sure that every single db execute gets a valid check
and at the same time return some kind of valuable db error to the user
and end the script.
How do you deal with db execution checks?
Thanks in advance!
Best regards.
Rico.
First, there are only a few ways a *true* error can occur with my
database. 1) Bad syntax from the programmer (me). 2) Bad input from the
user (which should never happen). 3) A catastrophic failure on the
database back end.
In all three cases, there is no recovery unless the programmer (me) digs
into the problem. Therefore, I have an error routine used for
everything, which dies and sends the programmer an email with a trace in
the case of a catastrophic error, like the above. And I have a database
wrapper class which checks for errors like this and fires the error
handler if the error is this bad. That means the script will abort and
the programmer will get an email.
Bear in mind, an error is *never* that a query returned no data or
data the user might consider bad.
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Best practice for if (!$stmt-execute())
On Mon, 25 Oct 2010 22:56:37 -0400 Paul M Foster pa...@quillandmouse.com wrote: Bear in mind, an error is *never* that a query returned no data or data the user might consider bad. This is an important point. When is an error an actual error? When is it something that *needs* to be logged and mailed? Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Best practice for if (!$stmt-execute())
On Tue, Oct 26, 2010 at 06:27:33AM +0200, Rico Secada wrote: On Mon, 25 Oct 2010 22:56:37 -0400 Paul M Foster pa...@quillandmouse.com wrote: Bear in mind, an error is *never* that a query returned no data or data the user might consider bad. This is an important point. When is an error an actual error? When is it something that *needs* to be logged and mailed? When it's a programmer/DBA error and cannot be recovered from. For example, the statement: SELECT * WHERE custno = 'BOBSMITH'; contains a syntax error (no table reference). That should generate a fatal error, because no such statement should ever be fired at the DBMS. The programmer should ensure his statements don't contain errors like that. And if they do, there's no way to fix it from a user's perspective. There are any of a number of other PHP errors which will generate error level messages which should lead to fatal errors. The code should now allow such errors. And no user input should create such errors. The programmer has to filter the user's input so that whatever he enters, it doesn't cause PHP or the DBMS to error out that way. These are just definitions of fatal errors from my perspective. Opinions may vary. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
