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

Help: Program flow when error in onclick event?

P: n/a
I was wondering,

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

In an <a> element:
onclick="zoomFullExtent(); 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
Jul 23 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Lee
Roland said:

I was wondering,

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

In an <a> element:
onclick="zoomFullExtent(); 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?


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.

Jul 23 '05 #2

P: n/a
Roland wrote:
I was wondering,

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

In an <a> element:
onclick="zoomFullExtent(); 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


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
Jul 23 '05 #3

P: n/a
"...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.

Jul 23 '05 #4

P: n/a
Gregory wrote:
"...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.
Yes, that's exactly what is required in most cases (of course we
speak in terms of our own experience here)
You will almost always want to return false. What you
probably want is something like this:

<a href="#" onclick="return zoomFullExtent();">link</a>
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.

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.


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
Jul 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.