[Javascript] JavaScript error reporting (was: Object reference usage (was Javascript and FF))

[tedd]

At 1:21 PM -0700 9/1/09, Paul Novitski wrote:
>At 9/1/2009 06:19 AM, tedd wrote:
>  >So why not leave in production alerts?
>
>I think it helps here to differentiate among at least four audiences
>for our JavaScript programs -- ourselves during development and
>deugging, ourselves after launch, our clients the website owners, and
>website visitors.

A good division of audiences, but I have a hard time dividing myself 
into before and after launch. :-)

---------
>I don't think it serves good purpose to inform a website visitor of
>low-level problems. I build pages that work without JavaScript, then
>add JavaScript as an enhancement.

I realize graceful degradation, but that really isn't a part of the 
"Why not show errors?" question. Alerts require javascript and if 
javascript isn't there, then the user doesn't see any errors anyway 
and thus my question is moot.

---------
-snip--

>  It would be irritating for visitors to have to click
>on alerts, a lot of the messages would be next to meaningless, there
>would be nothing they could do about the errors directly, and they
>would be left with a negative impression of the site ("It's broken").

That depends upon how the errors are presented. As a visitor to a 
site, I would rather see an explanation as to what went wrong rather 
than just have something not work right without an explanation.

As for users doing something about it, I agree that most users 
wouldn't normally do anything. But we still ask users to enter data 
properly, right? I don't really see the difference in asking a user 
to enter a date correctly (Y/M/D or M/D/Y) or telling them that 
something went wrong with the date they entered -- if you see what I 
mean?

This more of a human engineering problem.

---------
>Only a few of the grumpiest or geekiest would go out of their way to
>complain; I think most would simply leave, not come back, and not
>recommend the site to others.

I don't know -- do you have data to support your conclusion?

Let me ask you this, which is better on a car's dashboard, an 
idiot-light or a gauge? I like gauges. It doesn't mean I can fix the 
problem, but it gives me more information about what's wrong and 
makes me feel better. I can speak with authority to the mechanic by 
saying "This shows low oil pressure" rather than pointing to the 
idiot light that reads "Engine Needs Service Soon." I hate that light.

---------
>I feel that website visitors should be
>shielded from a website's dirty laundry; it's our business to provide
>the client's content agreeably on whatever level of functionality.

Again, I don't know. However, I do think that most of the "dirty 
laundry" can be sanitized for the viewing public. I also believe that 
if you inform your visitors as to what's happening (i.e., site is 
temporary closed for repairs) it's better than not (i.e., viewer sees 
a blank page).

---------
>I think it's a fair generalization to say that the vast majority of
>website clients are not technically web savvy and I tend to lump them
>with website visitors as far as low-level error reporting is concerned.

It's also a fair generalization to say that the vast majority of 
clients have problems with spelling and grammar, but I tend to inform 
them when they make a mistake. So why not let me know when I make a 
mistake? I have clients who inform me when they see something wrong 
and the sooner the better, am I right or am I right? Nothing is worse 
than the "Emperor's new clothes" syndrome.

---------
>After a website has launched and I've moved on to other projects, I'd
>rather use XMLHttpRequest to log the error in a database and/or send
>myself an email to alert myself to internal problems rather than to
>bother the visitor -- or the client, in most cases -- with runtime alerts.

That's a good idea -- namely, to have a system in place that lets you 
know when something goes wrong. I would like to know how to do that 
-- I'll look into it.

Because without knowing there's a problem, you can't fix it. And 
without alerts (or what you suggest) you'll never know there's a 
problem because no one will see the alerts and report the errors, 
which is/was my point.

Plus, we haven't discussed the documentation side of this.

In php, due to security concerns I usually have one session variable 
that controls all error reporting. During development it's turned on 
and afterwards for production it's turned off. However, all of the 
alerts are still there for future programmers to review. To me, it's 
just another part of the documentation.

The only difference between php and javascript is where the script 
resides and who can see it. Considering that javascript provides no 
security from prying eyes, then security concerns cannot be an issue 
-- not that you said otherwise.

So, the only real difference we have here is IF the users (including 
the client) can see any errors generated. Of course, this is only a 
theoretical discussion because we never release scripts that have 
errors anyway, right? :-)

But the discussion here is to the concept of including users' and 
clients' experiences as ways to improve the code rather than trying 
to hide errors from them. I am not suggesting using users and clients 
as beta-testers (like M$ does), but simply including them as part of 
the continuing process to improve the code.

Now what do you think?

Cheers,

tedd

-- 
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com