Re: Error handling strategies (db related)

On 27 April 2010 15:36, Paul M Foster <paulf@quillandmouse.com> wrote: > On Tue, Apr 27, 2010 at 10:42:03AM +0200, 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? > > 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. > Fair reasoning, but it amounts to throwing a bucket of cold water in the face of your user. If I was looking at an error like that, I'd get mighty annoyed with the software, and after a while would definitely look for alternatives. Whether or not there's a coding problem, you have to look at the situation from the point of the user: a complete failure with no information is like a BSOD/TSOD ... and we all know the effect they have on a user. Regards Peter -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 </hype>