Peter Lind wrote: > 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. I'm still shocked you guys are still writing code that has errors in it, what's worse is you know about the errors, and instead of fixing them you're just telling the user about it! :p -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
