[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