Javascript error checking

[Christopher Benson-Manica]

All right, since my previous idea (calling functions through a
wrapper) was apparently so awful no one could suggest any
improvements, I'll try a different tack. My end goal is to make
detecting and reporting script errors easy and painless. This could
be accomplished easily if window.onerror were ubiquitous, but it is
not. My new idea is to hack together something superficially
resembling C's assert() macro, perhaps something like

function assert( expr_as_string, cond ) {
var result=eval( expr_as_string );
if( cond == null ) {
cond=true;
}
if( result != cond ) {
alert( 'Assertion failed: '+expr_as_strin g+'=='+result+' , expected
'+cond );
return false;
}
return true;
}

which would be used like

assert( '5 != 3' ); // true
assert( '5*10 == 3' ); // false

Now obviously this is, again, probably unacceptably obfuscatory.
That's why I'm posting and hoping, desperately, for suggested
improvements and/or other ideas. Surely given the amount of script
that's out there someone has conceived a half-reasonable error checking
framework...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[nikki]

Surely given the amount of script
that's out there someone has conceived a half-reasonable error checking
framework...

Sure they have.
Firefox has Venkman and the javascript console, and MSIE has a windows
javascript debugger whose name I forget.

That (good testing using these tools) and try/catch and good coding
with checks (i.e. checking for object before using it) should handle
pretty much anything that comes up, really.

My 2 cents, of course.

[Baconbutty]

I would agree with nikki.

I have written an application running to some 1MB (60,000 lines) of
Javascript, with only object/property checking (and a single try catch
for file saving) , with no problems, so I struggle to see the uses of
an error checking framework. Could you give some examples of
applications you would use it in?

[Christopher Benson-Manica]

Baconbutty <ju****@baconbu tty.com> wrote:

I have written an application running to some 1MB (60,000 lines) of
Javascript, with only object/property checking (and a single try catch
for file saving) , with no problems, so I struggle to see the uses of
an error checking framework. Could you give some examples of
applications you would use it in?

So the 60,000 lines of script never, ever has unexpected bugs? I know
our script is written and tested by humans and occasionally bugs creep
in. If a Safari user encounters one of these bugs, how do you find
out about it? I'm really struggling to understand how you avoid ever
making a mistake in 60,000 lines of script.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Lee]

Christopher Benson-Manica said:

All right, since my previous idea (calling functions through a
wrapper) was apparently so awful no one could suggest any
improvements , I'll try a different tack. My end goal is to make
detecting and reporting script errors easy and painless. This could
be accomplished easily if window.onerror were ubiquitous, but it is
not. My new idea is to hack together something superficially
resembling C's assert() macro, perhaps something like

An important feature of assert() is that it can be compiled
out of the code for production release. Also, your assert()
will only be useful when checking global variables, since
variable names local to the calling function

Why not just add reasonable error checking to the code where
appropriate?

function myLibraryFuncti on(id, size, shape) {
if(size<MIN_SIZ E || size>MAX_SIZE || !validShape["SHAPE_"+sh ape]) {
alert(...)
return;
}
var ref=document.ge tElementById(id );
if(ref) {
} else {
alert("invalid id \""+id+"\" passed to myLibraryFuncti on");
}
...
}

[Lee]

Lee said:

Christopher Benson-Manica said:

All right, since my previous idea (calling functions through a
wrapper) was apparently so awful no one could suggest any
improvement s, I'll try a different tack. My end goal is to make
detecting and reporting script errors easy and painless. This could
be accomplished easily if window.onerror were ubiquitous, but it is
not. My new idea is to hack together something superficially
resembling C's assert() macro, perhaps something like

An important feature of assert() is that it can be compiled
out of the code for production release. Also, your assert()
will only be useful when checking global variables, since
variable names local to the calling function

[continuing that truncated paragraph]

variable names local to the calling function won't be available
in the scope of the eval() expression.

[Christopher Benson-Manica]

Lee <RE************ **@cox.net> wrote:

An important feature of assert() is that it can be compiled
out of the code for production release. Also, your assert()
will only be useful when checking global variables, since
variable names local to the calling function
Ey-yi-yi... well, so much for THAT plan. I actually don't want it
compiled out for a production release - a bug is a bug, and if the
script on a page is broken our users (and us!) need to know.
Why not just add reasonable error checking to the code where
appropriate?

Well, it seems that there is indeed no other choice, but it sure takes
up a lot of space. Additionally, the error handling is not always the
same, depending the UA (no lectures please) and whether the CGI
application is on a production or test system.

I appreciate the help, however.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[rich]

In article <11************ *********@z14g2 000cwz.googlegr oups.com>, Baconbutty
says...

I would agree with nikki.

I have written an application running to some 1MB (60,000 lines) of
Javascript, with only object/property checking (and a single try catch
for file saving) , with no problems, so I struggle to see the uses of
an error checking framework. Could you give some examples of
applications you would use it in?

Maybe it's just me but I've been spoiled by the debugger built-in to Perl.
Besides a basic syntax check, which usually causes problems somewhere in 60K
lines of code, you can also step through your script line by line and test
variables to make sure your program is doing what it's suppose to. Would be nice
to have a desktop tool for Javascript to test your scripts through and maybe
check for browser compatibility as a bonus.
Rich
--
Newsguy -- http://newsguy.com

[Baconbutty]

>>So the 60,000 lines of script never, ever has unexpected bugs?

I'm really struggling to understand how you avoid ever

making a mistake in 60,000 lines of script.

Sorry, I am probably not quite understanding the problem you are
seeking to solve, and as I am working alone I don't face the same
problems you may have of managing the inputs from several programmers:
so my example was unfair.

Don't get me wrong, during development there were plenty of bugs and
errors, usually to do with unexpected variable types (Javascript being
loosely typed) or bad logic, which I identified and corrected with the
brute force test and debug approach. .

In this, I tried to identify those functions which could cause damage
if they were the wrong data/or produced the wrong output, or which
relied on something external (e.g. initialising a component), and built
in specific tests, expectations and fall backs. It is here that I
would perhaps include error checking: i.e. mission critical functions.

But apart from that, once tested and debugged, there were relatively
few such functions, and the program in practice has usually failed me
only in very subtle ways to do with the logic of the program, which I
assumed no amount of error catching code could help with.

[Robert]

Christopher Benson-Manica wrote:

My new idea is to hack together something superficially
resembling C's assert() macro, perhaps something like

function assert( expr_as_string, cond ) {
var result=eval( expr_as_string );
if( cond == null ) {
cond=true;
}
if( result != cond ) {
alert( 'Assertion failed: '+expr_as_strin g+'=='+result+' , expected
'+cond );
return false;
}
return true;
}

which would be used like

assert( '5 != 3' ); // true
assert( '5*10 == 3' ); // false

I think what you are trying to accomplish is not bad.
Just like assert in Java it can also be useful in Javascript.
I find assert especially useful to check the pre-conditions of my methods.
I use a validate method myself at the start of a lot of methods to check
the argument types.
This will make the rest of my method body much simpler, because I do not
have to take into account all the ways someone could have called my method.

Anyway, what I do not understand is why you use a string argument for
assert and not something like:

Assert.assertEq uals(5, 3, "error message");

Personally I use a Application.deb ug variable if I don't want to do any
validation for example for production environments. Although I usually
just keep it on, because it can produce some useful stacktraces for me.