Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Javascript error checking

Reply
Thread Tools

Javascript error checking

 
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      10-06-2005
Baconbutty <(E-Mail Removed)> wrote:

> 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.


I think the difference is that your 60K lines were a
write-it-and-leave-it deal, whereas the scripts I'm dealing with are
constantly being updated and revised to provide new functionality, and
for better or worse there are several quite complex framesets with
heavily interlocked and mostly undocumented script. All manner of
things have and will go wrong, and in addition there are always little
browser-specific gotchas to worry about. The window.onerror handling
we have now just five minutes ago caught a Firefox-specific script
error that a user encountered that we might not otherwise have known
about.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
 
Reply With Quote
 
 
 
 
Baconbutty
Guest
Posts: n/a
 
      10-06-2005
>>whereas the scripts I'm dealing with are
>>constantly being updated and revised to provide new functionality, and
>>for better or worse there are several quite complex framesets with
>>heavily interlocked and mostly undocumented script.


You are right. I can see the problem you face. You need code to help
you make the best of the situation. Sorry I have not been able to
assist.

 
Reply With Quote
 
 
 
 
nikki
Guest
Posts: n/a
 
      10-06-2005

Christopher Benson-Manica wrote:
> Baconbutty <(E-Mail Removed)> wrote:
>
> I think the difference is that your 60K lines were a
> write-it-and-leave-it deal, whereas the scripts I'm dealing with are
> constantly being updated and revised to provide new functionality, and
> for better or worse there are several quite complex framesets with
> heavily interlocked and mostly undocumented script.


See, there's your problem right there.
Well-written code is both documented and encapsulated.
A function checks what it needs before using it. Since JS is not
strongly typed, check the argument types. Check for object existence
before using it. NO GLOBAL VARIABLES. And so on.
If you're writing things complex enough to look like java or C#, then
write it well like java or C#.
Smack other developers who make your life harder by not doing so. LOL

> All manner of
> things have and will go wrong, and in addition there are always little
> browser-specific gotchas to worry about.


I have yet to encounter a browser specific gotcha that was not easily
noticed by good object detection.
For example, older versions of Opera supported document.getElementById,
but not dynamic styles.
So to make sure it didn't crash, you could do this:

var myElement;
if (document.getElementById)
{
myElement = document.getElementById("elementId");
if (myElement.style && myElement.style.visibility)
{
myElement.style.visibility = "hidden";
}
}

You could add "else"s in there to inform you/the users about lack of
support for a feature.

Most scripts you see posted don't get that detailed (just not worth the
time for small sites, you know?), but if you have a huge amount of
code, in order for it to be production quality, these types of checks
need to run through the whole thing.
Use of these sorts of checks, combined with try/catch, encapsulation,
documentation, and getters/setters (typical OOP methods that provide
stability and prevent variables from being set to values they shouldn't
be set to, etc) would negate the need for an elaborate assertion
system.

 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      10-06-2005
nikki <(E-Mail Removed)> wrote:

> A function checks what it needs before using it. Since JS is not
> strongly typed, check the argument types. Check for object existence
> before using it. NO GLOBAL VARIABLES. And so on.


Right, but to be thorough one should really check everything, which
entails a significant performance hit when dealing with hundreds to
thousands of form fields.

> If you're writing things complex enough to look like java or C#, then
> write it well like java or C#.


It's a nice thought...

> So to make sure it didn't crash, you could do this:


Right, but if we did that everywhere the code would be extremely
mangled (although in places the indentation does a great job of
mangling by itself), and we would also be serving perhaps several
extra K of data with every page, which would definitely add up.

> Most scripts you see posted don't get that detailed (just not worth the
> time for small sites, you know?), but if you have a huge amount of
> code, in order for it to be production quality, these types of checks
> need to run through the whole thing.


Well, there's certainly a ton of code, but it generally flies by the
seat of its pants, as it were. If something unexpected happens, the
best it can do is inform us, the developers, so we can try to track it
down and eliminate it.

> Use of these sorts of checks, combined with try/catch, encapsulation,
> documentation, and getters/setters (typical OOP methods that provide
> stability and prevent variables from being set to values they shouldn't
> be set to, etc) would negate the need for an elaborate assertion
> system.


I suppose either one would require a substantial amount of work, as
well as buy-in from everyone else...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      10-07-2005
Robert <(E-Mail Removed)> wrote:

> I think what you are trying to accomplish is not bad.


I'm glad someone thinks the concept is worth thinking about, even if
it actually isn't workable in practice.

> I use a validate method myself at the start of a lot of methods to check
> the argument types.


That may be something to move toward, but it just doesn't exist right
now.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      10-07-2005
nikki <(E-Mail Removed)> wrote:

> 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.


Well, the point of this assert() idea was to start actually checking
types and existence of objects without being ridiculously verbose.
All that error checking and try/catch makes it that much more
difficult to get at the heart of what the script actually does, IMHO.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
 
Reply With Quote
 
Charles Harrison Caudill
Guest
Posts: n/a
 
      10-07-2005
Christopher Benson-Manica <(E-Mail Removed)> wrote:

> Now obviously this is, again, probably unacceptably obfuscatory.


javascript does pass-by-value for function pointers, ie it passes functions
not function pointers. you can also lambda stuff so:

assert(function(){var my = stuff + to + do; return var != null;}, true);

good luck lawn gnome,
Harrison

--
Harrison Caudill BS BS | .^ www.hypersphere.org
Computer Science & Physics Graduate | | Me*Me=1
Georgia Institute of Technology | v' I'm just a normal guy
 
Reply With Quote
 
Charles Harrison Caudill
Guest
Posts: n/a
 
      10-07-2005
nikki <(E-Mail Removed)> wrote:

> Christopher Benson-Manica wrote:
>> Baconbutty <(E-Mail Removed)> wrote:
>>
>> I think the difference is that your 60K lines were a
>> write-it-and-leave-it deal, whereas the scripts I'm dealing with are
>> constantly being updated and revised to provide new functionality, and
>> for better or worse there are several quite complex framesets with
>> heavily interlocked and mostly undocumented script.


> See, there's your problem right there.
> Well-written code is both documented and encapsulated.


This might be a newbie response, but I have a couple of helper functions for
my CNN owned implementation of sprintf, and I had to preface them with a
sprintf_ in the name just so that I could do this encapsulation. Javascript
strikes me as the type of language that is *meant* to entice suicide in the
programmer, kindof like squeak.

> A function checks what it needs before using it. Since JS is not
> strongly typed, check the argument types. Check for object existence
> before using it. NO GLOBAL VARIABLES. And so on.


That would be nice except that you don't have a main and you don't have static
variables inside of functions. How do you accomplish html templating stuff
without globals?

> If you're writing things complex enough to look like java or C#, then
> write it well like java or C#.


Here Here! If only there was a python-like client-side scripting language...

> Smack other developers who make your life harder by not doing so. LOL


I'd hand you the glove.

> I have yet to encounter a browser specific gotcha that was not easily
> noticed by good object detection.


In opera, file dialog boxes will, upon myBox.value, return just the file name,
not the fully qualified path. First you have to do, myBox.type = "text";,
to get the fully qualified path. IE and firefox don't require that.

> Most scripts you see posted don't get that detailed (just not worth the
> time for small sites, you know?), but if you have a huge amount of
> code, in order for it to be production quality, these types of checks
> need to run through the whole thing.
> Use of these sorts of checks, combined with try/catch, encapsulation,
> documentation, and getters/setters (typical OOP methods that provide
> stability and prevent variables from being set to values they shouldn't
> be set to, etc) would negate the need for an elaborate assertion
> system.


I'm with the lawn gnome here; I've gotten to the point where I'm developing a
set of javascript tools to deal with stuff like this, including debug.js.

-Harrison

--
Harrison Caudill BS BS | .^ www.hypersphere.org
Computer Science & Physics Graduate | | Me*Me=1
Georgia Institute of Technology | v' I'm just a normal guy
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Checking if the page IsValid in Javascript?! Emilio ASP .Net 6 02-18-2011 01:20 PM
javascript checking before submit butto Dariusz Tomon ASP .Net 2 07-14-2006 11:03 AM
Help: Javascript for checking user noor ASP .Net 1 12-24-2005 06:39 PM
Help : javascript for checking user noor ASP .Net 0 12-24-2005 08:37 AM
javascript for checking user Showjumper ASP .Net 2 12-24-2005 08:35 AM



Advertisments