Re: Error handling strategies (db related)
| From: | tedd | Date: | Tue, 27 Apr 2010 15:37:38 +0000 |
| Subject: | Re: Error handling strategies (db related) | ||
| References: | 1 2 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-304664@lists.php.net to get a copy of this message | ||
At 9:36 AM -0400 4/27/10, Paul M Foster wrote:
On Tue, Apr 27, 2010 at 10:42:03AM +0200, Gary . wrote:+1 I do something similar with the accounts I want to monitor. For example, when I access the database during development, I use code similar to this -- // --- script $sql = "SELECT * FROM users WHERE user_id = $uid "; $result = mysql_query($sql) or die(report($query,__LINE__ ,__FILE__)); // -- -- and then a "report" function similar to this -- // -- functions function report($query, $line, $file) { echo($query . '<br />' .$line . '<br />' . $file . '<br />' . mysql_error()); } // -- This provides me with information as to what happened and where. When the project goes live (out of development) then I replace the "report" function with code that can send me an email telling me what happened (to what domain) as well as an explanation to the user (screen display and sometimes even email) and sometimes an email is sent to the client (i.e., the user's credit card was denied for xxx reason trying to purchase product xxx at this date). Note, all my error reporting functions are located in a single function script that is included with every script that has access to the database. That way I can turn on/off error reporting and make alterations as to how to handle errors in one file. The difference between "development" and "live" is a simply a change in one script. Error handling is almost an art form. Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.comHow do you guys handle errors during, say, db insertions. Let's say you have an ongoing transaction which fails on the n-th insert. Ok, you roll back the transaction, no problem. How do you then inform the user? Just using the text from pg_result_error or something?I use trigger_error() and stop execution at that point. I give the user an error that basically says, "Talk to the admin/programmer". And I send the programmer a message containing a trace of what occurred. The theory is that, all things being equal, such an error should never occur and there is no user recovery. If the user properly entered the data they were asked for, then the transaction should go through without incident. If something prevents the transaction from going through, it's likely a coding problem and up to the programmer or admin to repair. Paul