Wrap function calls in try/except blocks

[Christopher Benson-Manica]

Thanks to the fact that Safari and other browsers have decided that
window.onerror is not worth supporting, I'm looking for a clean(er)
way to catch errors than simply tossing try/except blocks in every
single function. My initial thought (which strikes me as poor, hence
this post) is something like

function invoke( func_name ) {
var args=[];
for( var idx=1; idx < arguments.length; idx++ ) {
args.push( arguments[idx] );
}
try {
window[func_name].apply( null, args );
}
catch( ex ) {
if( windowOnErrorSupported ) { // figure this out elsewhere
throw ex; // Allow existing code to handle
}
else {
alert( 'Script error in '+func+': '+ex.message );
}
}
}

The creation of an array every time a function is called is what
really sours me on this idea. Also, I'm wondering about how to
determine whether window.onerror will actually work without detecting
the browser type. Obviously I could intentionally generate a script
error and see if it were properly handled by a dummy window.onerror,
but that also strikes me as a bad idea. Thanks heartily in advance
for any ideas.

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

[Richard Cornford]

Christopher Benson-Manica wrote:

Thanks to the fact that Safari and other browsers have
decided that window.onerror is not worth supporting, I'm
looking for a clean(er) way to catch errors than simply
tossing try/except blocks in every single function. ...

<snip>

Why don't you just learn to write defensive code that doesn't error-out,
like the rest of us learnt to do before we had the option of using
try-catch?

Richard.

[Christopher Benson-Manica]

(Sorry for posting from Google; my usual provider is having one of its
periodic unexplained outages.)

Richard Cornford wrote:

Why don't you just learn to write defensive code that doesn't error-out,
like the rest of us learnt to do before we had the option of using
try-catch?

Among other reasons:

1) 99.9% of this code is already written. It will be much
easier to catch errors as they occur rather than add tests to
hundreds of functions.
2) Much of the code is not written by me. It isn't my
decision, solely, to make.
3) It really strikes me as overkill to test every conceivable
error condition on the off chance that a bug will occur at
that point. Checking the value of five variables and the
existence of hundreds of form fields (not an exaggeration) is
really not preferable to just catching the occasional error
and reporting it so that it can be fixed.

[Richard Cornford]

Christopher Benson-Manica wrote:

Richard Cornford wrote:

Why don't you just learn to write defensive code that
doesn't error-out, like the rest of us learnt to do
before we had the option of using try-catch?
Among other reasons:

1) 99.9% of this code is already written.

Elaborating bad code is not a good idea. You just increase the ongoing
maintenance cost, and when it eventually becomes necessary to sort the
mess out there will be much more that needs sorting out. You cannot dig
your way out of a hole.
It will be much easier to catch errors as
they occur rather than add tests to
hundreds of functions.
But what you are proposing in rendering all function calls indirect, and
significantly restricting the possible employment of the language (all
functions called must be named properties of the window object, with the
usual implications for crowded global namespaces).
2) Much of the code is not written by me. It
isn't my decision, solely, to make.
Having less than competent colleagues is not an excuse for letting them
needlessly burden an ongoing project, and all of the others working on
that project.
3) It really strikes me as overkill to test every
conceivable error condition on the off chance that
a bug will occur at that point.
Errors are not things that happen randomly at any point. Most of the
time you know enough about the environment, the values you are using and
the actions you are taking to be certain of the outcome. Suitably
testing the few factors that remain unknown is not that much of a
burden.
Checking the value of five variables and the
existence of hundreds of form fields (not an exaggeration) is
really not preferable to just catching the occasional error
and reporting it so that it can be fixed.

If you are planning to fix the bugs before the completion of QA then
there is no reason to do anything. Browsers are quite capable of letting
you know when an uncaught exception is thrown (and being a lot more
explicit about where it was thrown than your code is even attempting).

Richard.

[Christopher Benson-Manica]

Richard Cornford <Ri*****@litotes.demon.co.uk> wrote:

Elaborating bad code is not a good idea. You just increase the ongoing
maintenance cost, and when it eventually becomes necessary to sort the
mess out there will be much more that needs sorting out. You cannot dig
your way out of a hole.
Whatever hole there is has already grown quite large, I'm afraid.
But what you are proposing in rendering all function calls indirect, and
significantly restricting the possible employment of the language (all
functions called must be named properties of the window object, with the
usual implications for crowded global namespaces).
Well, I did admit that it struck me as a lousy idea, which is why I
posted hoping for better suggestions.
If you are planning to fix the bugs before the completion of QA then
there is no reason to do anything. Browsers are quite capable of letting
you know when an uncaught exception is thrown (and being a lot more
explicit about where it was thrown than your code is even attempting).

The whole point of this exercise is that at least one browser we
attempt to support, Safari, by default handles uncaught exceptions by
completely hiding them. It's a ridiculous state of affairs, IMO.

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

[Richard Cornford]

Christopher Benson-Manica wrote:
<snip>

The whole point of this exercise is that at least one
browser we attempt to support, Safari, by default handles
uncaught exceptions by completely hiding them. It's a
ridiculous state of affairs, IMO.

To default to not popping up an error dialog is normal for web browsers.
Javascript error reports are of no value at all to the majority of users
(and might convince some that they were doing something wrong
themselves, when in fact they are compliantly blameless for errors).

You should only need to enable Safari's script error reporting mechanism
on development and QA machines, and there should be no good reason for
not doing so.

Richard.

[Christopher Benson-Manica]

Richard Cornford <Ri*****@litotes.demon.co.uk> wrote:

To default to not popping up an error dialog is normal for web browsers.
Javascript error reports are of no value at all to the majority of users
(and might convince some that they were doing something wrong
themselves, when in fact they are compliantly blameless for errors).

The contents of the error report are of no use, I agree. But knowing
an error occurred can be important - if nothing else, it will probably
spur a call to tech support, and a bug will be fixed. In browsers
that support window.onerror, one can catch script errors, report them
(we log them in a SQL database, and have caught many bugs we had never
found in our testing), and give the user a friendly "Oops, the
programmers screwed up, please call tech support" message.

Not popping up an error dialog is one thing, but trying to pretend
that nothing is wrong is ridiculous, IMO. A user shouldn't be able to
click on a button that happens to generate a script error and get no
clues that something is amiss. That is bad both for developers and
end users. Among other things, if a user does find an error in
Safari, how are the developers going to be sure they have reproduced
it if the only way to get useful information from the end user is to
have them edit some random text file so they can enable the JavaScript
console?

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

[Richard Cornford]

Christopher Benson-Manica wrote:

Richard Cornford wrote:

To default to not popping up an error dialog is normal
for web browsers. Javascript error reports are of no
value at all to the majority of users (and might convince
some that they were doing something wrong themselves,
when in fact they are compliantly blameless for errors).
The contents of the error report are of no use, I agree.
But knowing an error occurred can be important - if nothing
else, it will probably spur a call to tech support, and a
bug will be fixed.

Have you any idea how common script errors are on the public Internet?
Any user would soon tire of reporting them all, and rapidly see the
futility as they mostly exist in the first place because the author does
not know how to do any better and so cannot fix them.
In browsers that support window.onerror,
one can catch script errors, report them (we log them in a
SQL database, and have caught many bugs we had never
found in our testing),
But you are not looking to improve the quality of your testing?
and give the user a friendly "Oops,
the programmers screwed up,
Well, you said it. But QA seem to have also screwed up.
please call tech support" message.
There is nothing quite like trying to convince the users that you don't
know what you are doing.
Not popping up an error dialog is one thing, but trying to
pretend that nothing is wrong is ridiculous, IMO. A user
shouldn't be able to click on a button that happens to
generate a script error and get no clues that something is
amiss. That is bad both for developers and end users.
Among other things, if a user does find an error in Safari,
how are the developers going to be sure they have reproduced
it if the only way to get useful information from the end
user is to have them edit some random text file so they can
enable the JavaScript console?

LOL. You are a bunch of cowboys aren't you? (and apparently it is the
browser's fault).

Richard.