On 27 April 2010 16:24, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Apr 27, 2010 at 04:13:20PM +0200, Peter Lind wrote: > >> On 27 April 2010 16:07, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: >> > On Tue, Apr 27, 2010 at 03:41:04PM +0200, Peter Lind wrote: >> > >> >> On 27 April 2010 15:36, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> 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> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
