By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,797 Members | 1,315 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,797 IT Pros & Developers. It's quick & easy.

How to test for try/catch support

P: n/a

Hey all,

I'd like to start using the try/catch construct in some scripts. Older
browsers don't support this. What's the best way to test for support for this
construct so it doesn't kill non-supporting browsers?

TIA

--
--
~kaeli~
Contrary to popular opinion, the plural of 'anecdote' is
not 'fact'.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a


kaeli wrote:

I'd like to start using the try/catch construct in some scripts. Older
browsers don't support this. What's the best way to test for support for this
construct so it doesn't kill non-supporting browsers?


IE (at least on Win) supports try/catch since IE 5 thus if you still
care about IE 4 and want to protect IE 4 from seeing try/catch you could
use conditionals comments to check for the JScript version e.g.

/*@cc_on @*/
/*@if (@_jscript_version >= 5)
try {
...
} catch (e) {
...
}
@end @*/

Note that why I said above that it protects IE 4 against seeing the
try/catch it doesn't check the IE version but the JScript version which
is the proper approach as a system with IE 4 can nevertheless be updated
to have a newer version of JScript than the JScript 4 version IE 4 comes
with by default.
So the above gives you try/catch for those IE versions having a JScript
engines supporting try/catch while protecting IE versions having a
JScript version not supporting try/catch from seeing the script. However
other browsers not knowing about conditional comments will not see the
script either, even if they support try/catch.
--

Martin Honnen
http://JavaScript.FAQTs.com/
Jul 23 '05 #2

P: n/a
In article <42***********************@newsread2.arcor-online.net>,
ma*******@yahoo.de enlightened us with...


kaeli wrote:

I'd like to start using the try/catch construct in some scripts. Older
browsers don't support this. What's the best way to test for support for this
construct so it doesn't kill non-supporting browsers?


IE (at least on Win) supports try/catch since IE 5 thus if you still
care about IE 4 and want to protect IE 4 from seeing try/catch you could
use conditionals comments to check for the JScript version e.g.

/*@cc_on @*/


I care less about MSIE4 than any other browser.
If I just wanted to target version, I'd use the language attribute of the
script element, which is what I *may* end up falling back on.

Anyone else know a better way to check than
<script type="text/javascript" language="JavaScript1.5"> ?

--
--
~kaeli~
To steal ideas from one person is plagiarism; to steal from
many is research.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #3

P: n/a
In article <42***********************@newsread2.arcor-online.net>,
ma*******@yahoo.de enlightened us with...

IE (at least on Win) supports try/catch since IE 5 thus if you still
care about IE 4 and want to protect IE 4 from seeing try/catch you could
use conditionals comments to check for the JScript version e.g.


Also, from the Googling I'm doing now, it appears MSIE 5 did NOT orginally
support try/catch.
Apparently, try/catch support came with Javascript 1.5 (1.4 was on netscape
servers only), which didn't get implemented in MSIE until 5.5, not 5.0.

This has been helpful to me in my quest, if anyone else has been looking for
it:
http://www.afactor.net/toolbox/notes...atability.html

--
--
~kaeli~
Reading while sunbathing makes you well red.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #4

P: n/a
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.
Jul 23 '05 #5

P: n/a


kaeli wrote:

Also, from the Googling I'm doing now, it appears MSIE 5 did NOT orginally
support try/catch.


JScript 5 in IE 5 (Win) has supported try/catch from the beginning.
The only thing missing from standards compliance in regards to the
ECMAScript edition 3 exception handling in JScript 5 were 'finally' as in
try/catch/finally
and the properties of Error objects where JScript 5 has its own properties
description
number
while ECMAScript edition 3 specifies properties
name
message
which are only implemented since JScript 5.5 (came with IE 5.5).


--

Martin Honnen
http://JavaScript.FAQTs.com/
Jul 23 '05 #6

P: n/a
In article <d2*******************@news.demon.co.uk>,
Ri*****@litotes.demon.co.uk enlightened us with...

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)
From Martin's post, it seems it supports try/catch, but not finally. Since
the only time I ever bother with finally is with database and file
operations, I don't see a need for it for JS, personally.

Honestly, I have not used the try/catch mechanism at all, nor have I ever had
a need to, but I've never really coded JS as OOP, either, which I'm just
starting to play with (creating my own objects, that is). I'm so used to Java
I don't know how to code OOP without try/catch. LOL

I doubt I'll ever really make extensive use of it -- I'm just playing and the
thought came up.

I don't think that there is a good strategy for testing support for
try-catch in javascript versions.
I'm seeing that, yeah.
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).
True.
I just prefer to do as much as I can to not kill anyone's stuff. But if it's
a huge pain to do, they'll live. ;)

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.
That's because those people didn't use try/catch before, I'd bet. I wouldn't
bother with it if I wasn't going to do something with it.
Mostly I would use it just like I do in Java -- i.e. handling invalid values
in object property setters. For JS, the catch would either do something to
alert the user (if the value was from the user) or just fall back to a
default value (if the error was not from the user and they can't do anything
about it).
But like I said, this is mostly just at the "I was thinking about it" phase.

My guess is that if I start doing more with HTAs, I'll make a lot more use of
try/catch. But since the only thing I use those for is to make stuff for
myself, I don't know if I'll bother. :p
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.


I totally agree with you there. I have never needed try/catch before for
cross-browser code.
I really wouldn't even *need* it here; I just think it looks more OOP, so if
I'm doing things in an OOP way, it just makes sense to use it (especially if
I start throwing and handling my own error conditions). But it's easy enough
(though possibly messier code) to just use if/else.
--
--
~kaeli~
Once you've seen one shopping center, you've seen a mall.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #7

P: n/a
kaeli wrote:
Richard Cornford wrote:
The IE 5.0 version I use for testing has never
had its JScript version updated ( ... ) and it
has always supported try-catch ... <snip>
From Martin's post, it seems it supports try/catch, but
not finally. Since the only time I ever bother with finally
is with database and file operations, I don't see a need for
it for JS, personally.
Yes, I don't recall ever using - finally - in javascript so I have not
missed support for it. But then client-side code generally wouldn't get
involved in file or direct database access.
Honestly, I have not used the try/catch mechanism at all,
nor have I ever had a need to, but I've never really coded
JS as OOP, either, which I'm just starting to play with
(creating my own objects, that is). I'm so used to Java
I don't know how to code OOP without try/catch. LOL <snip>

It is not my perception that OO and try-catch are strongly interrelated.
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.


That's because those people didn't use try/catch before,
I'd bet.


Probably in many cases but I also see try-catch missed in javascript
that has been written by individuals I know to be experienced Java
programmers.

<snip> I really wouldn't even *need* it here; I just think it looks
more OOP, so if I'm doing things in an OOP way, it just makes
sense to use it (especially if I start throwing and handling
my own error conditions).
Designing javascript systems to use and throw their own custom
exceptions is where try-catch makes most sense in OO javascript. It
becomes a means of handling errors at an appropriate level without the
need to explicitly propagate error conditions up to those levels (using
function/method return values and the like). In a really controlled
environment (HTA, WSH, server-side, etc.), with a sufficiently complex
design requirement, that could often be objectively the best design
choice.
But it's easy enough (though possibly
messier code) to just use if/else.


I suspect that you will not find try-catch in javascript significantly
less 'messy' than if/else. In Java you can have multiple catch blocks
and catch exceptions of specific classes, or at various points in the
Exception class hierarchy. In general you would catch the types of
exceptions that it makes sense to handle locally and let other
exceptions go, to be handled at a higher level. It doesn't often make
sense to be catching the most general Exception class anywhere (at least
below the highest level).

In javascript you can only catch all exceptions and then examine them to
determine what type of exception they were (possibly re-throwing them if
necessary). Potentially that moves a lot of if/else code into the catch
block.

Richard.
Jul 23 '05 #8

P: n/a
>>From Martin's post, it seems it supports try/catch, but
not finally. Since the only time I ever bother with finally
is with database and file operations, I don't see a need for
it for JS, personally.
Yes, I don't recall ever using - finally - in javascript so I have not
missed support for it. But then client-side code generally wouldn't get
involved in file or direct database access.


finally is not exception mechanism, despite Java conflation.
finally is just an implied subroutine call. It makes up for Java 1.0's
lack of inner functions.

JavaScript's support for inner functions is nearly excellent. It does
not need finally.

http://www.JSLint.com
Jul 23 '05 #9

P: n/a
Douglas Crockford <no****@covad.net> writes:
finally is not exception mechanism, despite Java conflation.
I'll agree to that. It is, like exeception throwing and catching, a
control flow operation, but is otherwise unrelated.
finally is just an implied subroutine call. It makes up for Java 1.0's
lack of inner functions.
I disagree here. Finally is quite different from a subroutine call,
which is a simple call/return control flow operation. Finally adds
code to be executed upon control flow leaving a block *no* matter how
it happens - return, exception, or normal flow.

Finally is not *needed*, because you can perform the same operations
manually at all exit points of the block (which is where I guess the
subroutine comes in), but that is tedious and error prone (and
requires you to catch *all* exceptions from that block). Needing to
add a call more than one place is a prescription for errors.

And just as technically, exceptions are not needed either, because
you can encode it all in complex return values - but exceptions solve
the problem simpler and (therefore) safer.
JavaScript's support for inner functions is nearly excellent. It does
not need finally.


Nobody *needs* finally (or inner functions for that matter). It's
still a good help to write simpler, safer programs.

Javascript might not need finally as bad as other langauges because it
doesn't do allocation of resources in a way that requires
unpreventable, explicit deallocation, the typical use of finally in
Java.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #10

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:
It is not my perception that OO and try-catch are strongly interrelated.


Your perception is flawless :)

You have fully functional try/catch-operations in functional languages
like Standard ML (as a language feature) and Haskell (encoded in the
I/O-monad ... Haskell is big on monads). It existed in Ada and even in
variants of Forth.

You can add exceptions to anything that has a control flow.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #11

P: n/a
Lasse Reichstein Nielsen wrote:
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:
It is not my perception that OO and try-catch are strongly interrelated. Your perception is flawless :) You have fully functional try/catch-operations in functional languages
like Standard ML (as a language feature) and Haskell (encoded in the
I/O-monad ... Haskell is big on monads). It existed in Ada and even in
variants of Forth. You can add exceptions to anything that has a control flow.


While this is true, there is one strong interrelation: try-catch or
something similar brings sanity to handling the possibility of errors
inside constructors. That's why try-catch was introduced into C++ early on.

--
John W. Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like That.
....you may come to think a blow bad, because it hurts, and not because
it humiliates. You may come to think murder wrong, because it is
violent, and not because it is unjust."
-- G. K. Chesterton. "The Ball and the Cross"
Jul 23 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.