Re: Error handling strategies (db related)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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".

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



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux