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. > > > 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
