Error handling strategies (db related)
in [General]
|
Prev: Contact form....
Next: special character problem
From: "Gary ." on 27 Apr 2010 10:04 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.
From: Paul M Foster on 27 Apr 2010 10:07 On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: > 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. I assume (1) that I've vetted the user data and given them the option to repair it if it's faulty; (2) beyond the beta phase, this type of error should not happen. If it does, it's a coding problem. Given that the user can do *nothing* about this and it *is* a coding problem, what would you tell the user? If I was the user, I'd be cranky as well. But if I were a smart user, I'd realize that the programmer made a mistake and put the responsibility firmly on him. And expect him to fix it pronto. Paul -- Paul M. Foster
From: Peter Lind on 27 Apr 2010 10:13 On 27 April 2010 16:07, Paul M Foster <paulf(a)quillandmouse.com> wrote: > On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: > >> 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. > > I assume (1) that I've vetted the user data and given them the option to > repair it if it's faulty; (2) beyond the beta phase, this type of error > should not happen. If it does, it's a coding problem. Given that the > user can do *nothing* about this and it *is* a coding problem, what > would you tell the user? "Sorry, but there was a problem inserting the data into the database. The developers have been notified about this error and will hopefully have it fixed very soon. We apologize for the inconvenience." At the very least, something along those lines. > If I was the user, I'd be cranky as well. But if I were a smart user, > I'd realize that the programmer made a mistake and put the > responsibility firmly on him. And expect him to fix it pronto. If only the world consisted of smart users ... I think, however, that we're generally closer to the opposite. And no, I don't hate users - I've just seen too many people do things that were very far removed from "smart". 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: Paul M Foster on 27 Apr 2010 10:24 On Tue, Apr 27, 2010 at 04:13:20PM +0200, Peter Lind wrote: > On 27 April 2010 16:07, Paul M Foster <paulf(a)quillandmouse.com> wrote: > > On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: > > > >> 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. > > > > I assume (1) that I've vetted the user data and given them the option to > > repair it if it's faulty; (2) beyond the beta phase, this type of error > > should not happen. If it does, it's a coding problem. Given that the > > user can do *nothing* about this and it *is* a coding problem, what > > would you tell the user? > > "Sorry, but there was a problem inserting the data into the database. > The developers have been notified about this error and will hopefully > have it fixed very soon. We apologize for the inconvenience." > > At the very least, something along those lines. Well of course. No reason to slap the user in the face. I agree. But in the end, this is about the same as saying, "Talk to the programmer", just a nicer way of saying it. > > > If I was the user, I'd be cranky as well. But if I were a smart user, > > I'd realize that the programmer made a mistake and put the > > responsibility firmly on him. And expect him to fix it pronto. > > If only the world consisted of smart users ... I think, however, that > we're generally closer to the opposite. And no, I don't hate users - > I've just seen too many people do things that were very far removed > from "smart". Unfortunately, true. Sometimes I think computer users should be required to take a course in using a computer before being allowed behind the keyboard. Paul -- Paul M. Foster
From: Peter Lind on 27 Apr 2010 10:31
On 27 April 2010 16:24, Paul M Foster <paulf(a)quillandmouse.com> wrote: > On Tue, Apr 27, 2010 at 04:13:20PM +0200, Peter Lind wrote: > >> On 27 April 2010 16:07, Paul M Foster <paulf(a)quillandmouse.com> wrote: >> > On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: >> > >> >> 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. >> > >> > I assume (1) that I've vetted the user data and given them the option to >> > repair it if it's faulty; (2) beyond the beta phase, this type of error >> > should not happen. If it does, it's a coding problem. Given that the >> > user can do *nothing* about this and it *is* a coding problem, what >> > would you tell the user? >> >> "Sorry, but there was a problem inserting the data into the database. >> The developers have been notified about this error and will hopefully >> have it fixed very soon. We apologize for the inconvenience." >> >> At the very least, something along those lines. > > Well of course. No reason to slap the user in the face. I agree. But in > the end, this is about the same as saying, "Talk to the programmer", > just a nicer way of saying it. Of course, it's just a question of degree. If the user can't correct the error, there's only one person that can: the programmer. Question is what you tell the user in that situation. >> >> > If I was the user, I'd be cranky as well. But if I were a smart user, >> > I'd realize that the programmer made a mistake and put the >> > responsibility firmly on him. And expect him to fix it pronto. >> >> If only the world consisted of smart users ... I think, however, that >> we're generally closer to the opposite. And no, I don't hate users - >> I've just seen too many people do things that were very far removed >> from "smart". > > Unfortunately, true. Sometimes I think computer users should be required > to take a course in using a computer before being allowed behind the > keyboard. > While I love to rant at stupid users, the truth is probably that programmers are the ones who should take courses in how users think. In the end, if I fail to understand my users, it doesn't matter how great my program is: they'll still fail to use it. Anyway, those are just truisms :) Nothing new under the sun. 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> |