From: Nathan Rixham on
Peter Lind wrote:
> On 27 April 2010 16:24, Paul M Foster <paulf(a)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 <paulf(a)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 <paulf(a)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.

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
From: Teus Benschop on
> 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!
>

The point here is that we, programmers, know that we write code with
bugs in it. We are realistic about it, that is, we know that perfect
code does not exist, and that there are bugs in it. So what we care
about is to bring this reality to the users in a gracious manner. And
the other thing is that if for example a database is down, that is not
our fault, it is an external error, but this error should be brought to
the user as well. Teus.

From: Nathan Rixham on
Teus Benschop wrote:
>> 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!
>>
>
> The point here is that we, programmers, know that we write code with
> bugs in it. We are realistic about it, that is, we know that perfect
> code does not exist, and that there are bugs in it. So what we care
> about is to bring this reality to the users in a gracious manner. And
> the other thing is that if for example a database is down, that is not
> our fault, it is an external error, but this error should be brought to
> the user as well. Teus.
>

had hoped the addition of a (now stripped) :p emote would ensure taking
the above as a joke tbh ;)

regardless, might I add that exceptions or errors mapped through to the
appropriate HTTP status code and a friendly site specific error document
may be a good way to proceed.

A good example of friendly error documents can be seen at most of the
major sites around the web that we all frequent (or are at least aware of).

Further, these friendly documents make it clear that the error is a
server / application error and that no action the user takes will fix
the error.

Best,
From: tedd on
At 4:13 PM +0200 4/27/10, Peter Lind wrote:
>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

Peter et al:

Smart is a relative term. I have one account where the majority of
users are PhD's -- and they indeed have the "smarts" and the
sheepskins to prove it.

You would be surprised as to how many of those forget their logons
and insist that they did not enter their logons as they were
recorded. For example, I had one user (i.e., fictitious Mary Smith)
who said that "marysmith" was not her logon because she always uses
"msmith" for all her logons -- but that was what was recorded in the
database.

I tried to explain to her that the database doesn't make this stuff
up, for example how would the script know to use "marysmith" for her
logon if she had not provided it? But somehow it was the script's
fault for not knowing she always uses "msmith". Keep in mind these
are people with PhD's. I have many other stories.

As I see it, one of the problems we face as developers is confronting
user's egos. They have an image of themselves and our scripts can
threaten that image by making them feel ignorant. We have to deal
with that in a way that informs them, but doesn't demean them in any
fashion.

Here's a real world example -- over 20 years ago a company made an
electronic hand-held chess game.

While the game was successful, the company received a considerable
amount of repairs, way over what they had expected. They wanted to
find out why and after an investigation they found that their
software made the computer's chess-moves TOO quickly. So, they place
a time delay into the software so that it would "look" to the user
like the computer was thinking about its moves. That time-delay
solved the problem.

Apparently, some end-users got pissed when they thought the computer
could so easily beat them. But, if the computer took more time to
beat them, then that was more acceptable and the end-users were less
inclined to throw the game into a wall.

So with respect to software engineering, how users view what's going
on is important.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
From: tedd on
At 10:24 AM -0400 4/27/10, Paul M Foster wrote:
>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

Yeah, like I believe that everyone should do through at least one
divorce before getting married.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Contact form....
Next: special character problem