On Tue, Apr 27, 2010 at 7:34 PM, Gary . <php-general@xxxxxxxxxxxxxxx> wrote: > On Tue, Apr 27, 2010 at 10:46 AM, Peter Lind wrote: >> On 27 April 2010 10:42, Gary . wrote: >>> How 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? >>> >> >> If it's a normal user, give them some info about what went wrong but >> not the specific error returned. > > Yeah. I know :( Originally I couldn't find a "nice" way of translating > between db errors and "user" errors. The only interface to the db > errors that I could find was the error messages returned from > pg_last_error. Yes, I could have used an array translating between the > the strings returned by pg_last_error or whatever, but *gag* it would > not only have made the code look horrible but would also have been > susceptible to changes in the error messages returned by the db > interface. In the end I changed tack slightly and used pg_send_* and > pg_result_error_field to get a short code I could use as a reference > into an array. thought of adding few extra things i do. i keep a constant to check the running environment. before i do the 'trigger_error' with pg/mysql raised error, i conditionally check whethr it's 'live', 'beta' or 'dev' environment and use different error_handlers. if it's 'production' environment, the error handler will write the detail error with all back-trace and possible sql queries and data into a log file with a unique id, and displays a friendly message with that reference id, so the user can report to sys admin if he/she wishes. ~viraj > > -- > 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
