kaeli wrote:
<snip>
... , it appears MSIE 5 did NOT
orginally support try/catch.
Apparently, try/catch support ...
<snip> ... which didn't get implemented in MSIE until
5.5, not 5.0.
I wouldn't trust that. The IE 5.0 version I use for testing has never
had its JScript version updated (it is on an old computer that doesn't
get used for much else but testing with old browsers) and it has always
supported try-catch without any problems (though there is plenty of ECMA
262 3rd edition that is not in that JScript version)
I don't think that there is a good strategy for testing support for
try-catch in javascript versions. The problem being that its use is a
syntax error in earlier versions because try-catch were reserved words.
Runtime errors being much easier to cope with.
The most viable strategy I have seen proposed is to present the
try-catch code as a string, so that it is not a syntax error as such,
and then execute that string at runtime using something like - (new
Function('try{;}catch(e){;}'))(); - (obviously there is an alternative,
an application of - eval -, but lets not go there as it is not required
;) having set up a - window.onerror - handler for just the duration of
the function call. If the try-catch code generates an error while it
executes the onerror handler is called and flags the try-catch code as
non-viable.
That strategy is viable for Netscape 4 and IE 4 but less successful with
other older browsers as - window.onerror - is itself by no means
standard or reliable. Konqueror 2, for example, lacks support for
try-catch and window.onerror, so the strategy might be better than
nothing but cannot achieve the stated goal.
To be honest I think we are approaching the point where ECMS 262 3rd
edition support for try-catch could be assumed. That is; the pre
try-catch browsers are getting so old now that few of them are going to
be of much use on the current Internet (and you know me well enough to
appreciate that I do not say that lightly).
There are facilities on modern browsers, such as xmlhttp requests, that
can be employed to advantage, and in a way that facilitates clean
degradation where not (fully) supported (such as disabled ActiveX), but
not without try-catch.
On the other hand I don't like try-catch too much. I have seen too many
examples of it being used to conceal runtime error rather than to
actually handle them. They make it all to easy to deal with code that
sometimes produces errors by wrapping it in try-catch rather than
understanding the error and devising a test that will identify the
conditions that cause it so they can be avoided.
Those of us that have been writing cross-browser code that exhibits
planned behaviour in the face of any execution environment without ever
showing javascript errors to the user, and without the option of using
try-catch, have learnt that code that is appropriately defensive is not
really that difficult to write and that javascript is very good at
examining its environment for the conditions and features it intends to
employ.
The web application that I am working on at present is only expected to
work with recent IE versions and Mozilla/gecko browsers so try-catch is
not an issue. Yet in what is now more than 10,000 lines of client-side
code there are not more than half a dozen try-catch blocks, wrapping
less than 30 lines of code. All of the many other potentially error
producing conditions are handled by suitable design and defensive code
that tests up front, rather than erroring and then trying to recover.
Incidentally, try the language="JavaScirpt1.5" idea out on some IE
versions before going too far in that direction. You will probably
conclude that it is not very viable either.
Richard.
