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