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

Reply via email to