On 27 April 2010 16:24, Paul M Foster <pa...@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 <pa...@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 <pa...@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.


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

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to