Help: Program flow when error in onclick event?

[Roland]

I was wondering,

what happens when you have an onclick event and an error occurs in it:

In an <a> element:
onclick="zoomFu llExtent(); return false;"

I know that there is an error happening in zoomFullExtent. I didn't
define my own error handler, so the default one is used.(My browser is
Firefox 1.0).

I notice that when this error happens, the browser makes a request to
the server.
I thought that if an error happened in zoomFullExtent, the default
error handler would catch it, and then zoomFullExtent would return
normally. But that doesn't seem to happen. Instead the whole onclick
script returns or is aborted? And it seems to return true so that the
request is made. Is there a page where this program flow is explained?

Thanks for reading,

Roland

[Lee]

Re: Help: Program flow when error in onclick event?

Roland said:[color=blue]
>
>I was wondering,
>
>what happens when you have an onclick event and an error occurs in it:
>
>In an <a> element:
>onclick="zoomF ullExtent(); return false;"
>
>I know that there is an error happening in zoomFullExtent. I didn't
>define my own error handler, so the default one is used.(My browser is
>Firefox 1.0).
>
>I notice that when this error happens, the browser makes a request to
>the server.
>I thought that if an error happened in zoomFullExtent, the default
>error handler would catch it, and then zoomFullExtent would return
>normally. But that doesn't seem to happen. Instead the whole onclick
>script returns or is aborted? And it seems to return true so that the
>request is made. Is there a page where this program flow is explained?[/color]

It doesn't have to return true. The link is followed unless the onclick handler
specifically returns false. The best solution is probably to avoid using a link
in that case.

[RobG]

Re: Help: Program flow when error in onclick event?

Roland wrote:[color=blue]
> I was wondering,
>
> what happens when you have an onclick event and an error occurs in it:
>
> In an <a> element:
> onclick="zoomFu llExtent(); return false;"
>
> I know that there is an error happening in zoomFullExtent. I didn't
> define my own error handler, so the default one is used.(My browser is
> Firefox 1.0).
>
> I notice that when this error happens, the browser makes a request to
> the server.
> I thought that if an error happened in zoomFullExtent, the default
> error handler would catch it, and then zoomFullExtent would return
> normally. But that doesn't seem to happen. Instead the whole onclick
> script returns or is aborted? And it seems to return true so that the
> request is made. Is there a page where this program flow is explained?
>
> Thanks for reading,
>
> Roland[/color]

Uncaught errors may exit one or more execution contexts - so it is
possible for an error in 'zoomFullExtent ()' to cause your onclick to
exit. If that happens, your onclick will return something other than
'false' and the link will be followed.

Where an onclick is used to intercept the default action of an HTML
element (say an <a href="... ), it is normal for the function to
return an appropriate value that controls whether or not the action
is performed, e.g.

<a href="..." onclick="return zoomFullExtent( );" ...>

and in zoomFullExtent( ):

function zoomFullExtent( ){
var OK = false;

// do some stuff, test that everything works as expected

if ( /* everything OK */ ) {
OK = true;
}
return !OK;
}

This may not suit you in this case though. Look in the ECMA spec
section 10.2.

--
Rob

[Gregory]

Re: Help: Program flow when error in onclick event?

"...it is normal for the function to return an appropriate value that
controls whether or not the action is performed"

No, actually, with click handlers on buttons and links, returning true
or null will allow the link to be processed as if your click handler
didn't exist. You will almost always want to return false. What you
probably want is something like this:

<a href="#" onclick="return zoomFullExtent( );">link</a>

and in zoomFullExtent( ):


var debug = true;
function zoomFullExtent( ) {
try {
//do your normal stuff
} catch( e ) {
if( debug ) alert( "Error in zoomFullExtent: " + e );
}

return false;
}

Note that the try...catch blocks handle any errors you receive. Setting
debug to false will hide the errors from end users. And, most
importantly, the function always returns false.

[RobG]

Re: Help: Program flow when error in onclick event?

Gregory wrote:[color=blue]
> "...it is normal for the function to return an appropriate value that
> controls whether or not the action is performed"
>
> No, actually, with click handlers on buttons and links, returning true
> or null will allow the link to be processed as if your click handler
> didn't exist.[/color]

Yes, that's exactly what is required in most cases (of course we
speak in terms of our own experience here)
[color=blue]
> You will almost always want to return false. What you
> probably want is something like this:
>
> <a href="#" onclick="return zoomFullExtent( );">link</a>[/color]

No, you want the onclick handler to do something and if the
client-side JavaScript does not do it, then the link should head off
to the server where something appropriate happens - either the
functionality is provided server-side or an explanation is given as
to why it didn't happen.

Therefore only if the script does what it's supposed to should
'false' be returned. Any other value causes the link to be followed -
this logic is inherent in the architecture of intrinsic events.
[color=blue]
>
> and in zoomFullExtent( ):
>
>
> var debug = true;
> function zoomFullExtent( ) {
> try {
> //do your normal stuff
> } catch( e ) {
> if( debug ) alert( "Error in zoomFullExtent: " + e );
> }
>
> return false;
> }
>
> Note that the try...catch blocks handle any errors you receive. Setting
> debug to false will hide the errors from end users. And, most
> importantly, the function always returns false.
>[/color]

So if the script errors, nothing useful happens? It also suggests
that all functions called by intrinsic events should have try/catch
blocks. Some of the more learned contributors may wish to comment on
that proposition.


--
Rob