Error handling strategies (db related)
in [General]
|
Prev: Contact form....
Next: special character problem
From: "Gary ." on 27 Apr 2010 04:42 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?
From: Peter Lind on 27 Apr 2010 04:46 On 27 April 2010 10:42, Gary . <php-general(a)garydjones.name> 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. If it's an admin with dev knowledge (i.e. you) then consider handing out the returned error as well. Rule of thumb: aim to inform the user without confusing. There's nothing worse than "This didn't work, sorry" - why didn't it work?? Was it my fault? Can I get it to work somehow? 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>
From: Michiel Sikma on 27 Apr 2010 06:44 On 27 April 2010 10:42, Gary . <php-general(a)garydjones.name> 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? > > Developers are usually lazy about error reporting because it's much easier to just return the error code. Some parsing is very useful to the user, since overtly technical information is just confusing. The error should never be something that the user himself can avoid (since you're supposed to have error checking and handling before the user submits), so your error should make this clear to him. It helps to let him know that the developer has been notified and that he can try again later. Michiel
From: Paul M Foster on 27 Apr 2010 09:36 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. Paul -- Paul M. Foster
From: Peter Lind on 27 Apr 2010 09:41
On 27 April 2010 15:36, Paul M Foster <paulf(a)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> |