In article <d2hssp$9k8$1$8302bc10@news.demon.co.uk>,
Richard@litotes.demon.co.uk enlightened us with...[color=blue]
>
> 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)[/color]
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.
[color=blue]
>
> I don't think that there is a good strategy for testing support for
> try-catch in javascript versions.[/color]
I'm seeing that, yeah.
[color=blue]
> 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).[/color]
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. ;)
[color=blue]
>
> 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.[/color]
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
[color=blue]
> 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.[/color]
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 
