[Javascript] JavaScript error reporting (was: Object reference usage (was Javascript and FF))
Paul Novitski
paul at juniperwebcraft.com
Tue Sep 1 15:21:46 CDT 2009
At 9/1/2009 06:19 AM, tedd wrote:
>At 11:32 AM -0700 8/31/09, Paul Novitski wrote:
>>(Those return alerts are purely for logic illustration and aren't
>>what I do in production code.)
>
>Why not?
>
>I can see hiding errors from hackers when writing server-side
>scripts, because you don't want to give them any information that
>they may of use against your code. But with client-side scripts, the
>hackers have all the code -- so who cares if they see an error or
>not? What harm does it do?
>
>Additionally, I would rather have a client say "Your code doesn't
>work -- it report 'Paragraph is empty'" than say ""Your code doesn't work".
>
>In addition, the client might even look at the error and think it's
>their fault and provide a solution themselves (i.e., add a paragraph).
>
>Additionally, later when you (or another programmer) review the code
>alerts provide great documentation.
>
>So why not leave in production alerts?
Thanks, Tedd; really great topic.
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.
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. If the user agent that downloads
the page doesn't have a JavaScript interpreter running for whatever
reason, or if it does but it's too old to understand the DOM, my
pages should still work just fine (just perhaps not as responsively
or sexily). This means that if my script runs into a situation it
can't handle, such as a crucial element not found, it can quit
quietly and still leave the user with a functional page. (It's
important to test for the presence of critical elements early in a
script so it's less likely to fail with a user interface
half-rendered.) 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").
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 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.
I rely on temporary alerts among other tools when debugging a
stubborn script, but the vast majority of those alerts are for my
eyes only and don't belong in the code, at least not uncommented. I
can see the purpose of retaining certain low-level error messages for
a client who can either fix the problem or let me know there is one,
but I would want the messages to be for their eyes only. One way to
do this would be to let the client log in so there's a cookie to let
JavaScript know it's OK to say Ouch. I've done this server-side and
never in JavaScript but it would be easy enough to implement. However
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.
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.
Regards,
Paul
__________________________
Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com
More information about the Javascript
mailing list