In my web searches on DOM access, I found someone saying that they have thousands
of calls to a function, and they had an exception handler to determine if a certain
browser function was there, and if not, to do some other longer equivalent thing.
But it raises the question in my mind of how expensive exceptions are in javascript.
Are they time consuming, or are they lightweight and usable without regard?

My thinking would be that if they are expensive, I'd run it once, with exception,
but have a global flag that said it failed, which would switch to the alternative.
That would be complex though, given nested functions aren't allowed.

/Matthew Jones/

Matthew,

<< In my web searches on DOM access, I found someone saying that they have
thousands of calls to a function, and they had an exception handler to
determine if a certain browser function was there, and if not, to do some
other longer equivalent thing. But it raises the question in my mind of how
expensive exceptions are in javascript. Are they time consuming, or are they
lightweight and usable without regard? >>

I wouldn't worry about them unless you have a demonstrable performance
problem in a particular browser.  However, having said that, I would *not*
use them for the task outlined above - it's way easier to just test for the
existence of the function or some other equivalent code that doesn't use
exceptions.

<< My thinking would be that if they are expensive, I'd run it once, with
exception, but have a global flag that said it failed, which would switch to
the alternative. That would be complex though, given nested functions aren't
allowed. >>

I don't see the complexity involved (???) - EWB's framework has similar
global flags/functions all over that indicate capabilities of the browser,
etc.  With things like initialization/finalization sections, it's really no
big deal to set these flags once and forget about them.

Tim Young
Elevate Software
www.elevatesoft.com