> -----Original Message----- > From: Rico Secada [mailto:coolzone@xxxxx] > Sent: Sunday, October 24, 2010 9:06 PM > To: php-general@xxxxxxxxxxxxx > Subject: 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
