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.


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