Preserved Topic: window.onerror = null; does it really work? (Page 1 of 1)

try this:

<script>

window.onerror = null;

window.asdfasdad();

</script>

you will notice that the error was not silent and instead it still showed the error handler...

now try this:

<script>

window.onerror = new Function("return true;");

window.asdfasdad();

</script>

you'll notice that the error is really swallowed!


am i missing something?

(i bring up this topic because i'm seeing all the time the: window.onerror = null; which appeared not to work with me)

I don't rightly know. By the time I ever got around to adding in the window.onerror = null; i was no longer getting any errors. :P

Maybe window.onerror = null; only stops errors being thrown for older browsers. As I recall there were some JS 1.1 tricks you could do with the document.images model for NN and IE3. It worked for IE3 but it still threw errors. So it could just be a depreciated method. After all, if the null value is unable to be assigned to winrow.onerror then wouldn't this throw an error itself?

On the other hand, I could be way off.

Yeah, actually, that looks like it would work pretty well, though I might have returned false instead? window.onerror = null always only worked for *some* errors, while other, more major errors would slip by. I'm going to give that a try myself, it looks good to me! I'll also have to then look around for pages thast give erros though, heh.

Your pal, -doc-

I think i read some were that "window.oneror = null" only works in netscape, is that true?

"Works in Netscape?" Can't be true. =)

Well, it seemed to work in everything but Opera for me, and I had to work pretty hard to get it to start reporting errors to me, so I don't want it to stop! =) FWIW, the string I'm using, which is now implemented throughout the OZONE site is this...

window.onerror = function() { return false; }

... and I've tested it with some very obvious errors that would usually have thrown an alert to me, hearing nothing! Great tip lallous, thanks!

Your pal, -doc-

window.onerror = function() { return false; }

Doc, didn't you mean 'return true' instead?

cause 'false' signals that the error was not handled therefore the errorbox will still appear, no?

You're right slime nothing works in netscape he he,

Hmm, I have to admit that... I'm not sure. "return false" seems to indicate that whatever script we were in the middle of should stop now, no more, uh-uh. I really did test this, and it worked as hoped, so I can't really say. I'll wait for comments from one of our more professional programmers here, they know this kind of stuff, I'm sure! Guys?

Your pal, -doc-

Doc, in the name of the JavaScript bible gold edition 4:

quote:

---

The onerror property is an exception to the rule of this book to not describe
event handlers as properties within object reference sections. The reason is that
the onError event brings along some special properties that are useful to control
by setting the event handler property in scripts.
Recent browsers (IE5+ and NN4+) are designed to prevent script errors from being
intrusive if a user encounters a script error while loading or interacting with a page.
Even so, even the subtle hints about problems (messages or icons in the statusbar)
can be confusing for users who have no idea what JavaScript is. JavaScript lets you
turn off the display of script error windows or messages as someone executes a
script on your page. The question is: When should you turn off these messages?
Script errors generally mean that something is wrong with your script. The error
may be the result of a coding mistake or, conceivably, a bug in JavaScript (perhaps
on a platform version of the browser that you haven?t been able to test). If such
errors occur, often the script won?t continue to do what you intended. Hiding the
script error from yourself during development would be foolhardy, because you?d
never know whether unseen errors are lurking in your code. It can be equally dan-gerous
to turn off error dialog boxes for users who may believe that the page is
operating normally, when, in fact, it?s not. Some data values may not be calculated
or displayed correctly.
That said, I can see some limited instances of when you may want to keep such
dialog box windows from appearing. For example, if you know for a fact that a plat-form-
specific bug trips the error message without harming the execution of the
script, you may want to prevent that error alert dialog box from appearing in the
files posted to your Web site. You should do this only after extensive testing to
ensure that the script ultimately behaves correctly, even with the bug or error.
IE fires the onError event handler only for runtime errors. This means that if you
have a syntactical error in your script that trips the browser as the page loads, the
onError event doesn?t fire, and you cannot trap that error message. Moreover, if
the user has the IE script debugger installed, any code you use to prevent browser
error messages from appearing will not work.
When the browser starts, the window.onerror property is <undefined>. In this
state, all errors are reported via the normal JavaScript error window or message. To
turn off error alerts, set the window.onerror property to invoke a function that
does absolutely nothing:
function doNothing(){return true}
window.onerror =doNothing
To restore the error messages, reload the page.
You can, however, also assign a custom function to the window.onerror prop-erty.
This function then handles errors in a more friendly way under your script
control. Whenever error messages are turned on (the default behavior), a script
error (or Java applet or class exception) invokes the function assigned to the
onerror property, passing three parameters:
.Error message
.URL of document causing the error
.Line number of the error
You can essentially trap for all errors and handle them with your own interface
(or no user notification at all). The last statement of this function must be return
true if you do not want the JavaScript script error message to appear.
NN6 does not pass error-related parameters to a function invoked by onError . This
may be an attempt to lure scripters to the more modern try-catch error trapping
mechanism (see Chapter 39). But it means that NN6 cannot take complete advan-tage
of older error reporting code, including that shown in Listing 16-10.
If you are using LiveConnect to communicate with a Java applet or (in NN3+) to
call up Java class methods directly from your scripts, you can use the same scheme
to handle any exception that Java may throw. A Java exception is not necessarily a
mistake kind of error: Some methods assume that the Java code will trap for excep-tions
to handle special cases (for example, reacting to a user?s denial of access
when prompted by a signed script dialog box). See Chapter 44 for an example of
trapping for a specific Java exception. Also, see Chapter 39 for JavaScript exception
handling introduced for W3C DOM-compatible browsers.
Example (with Figure 16-6 and Listing 16-10) on the CD-ROM
Related Items: location.reload()method; JavaScript exception handling
(Chapter 39); debugging scripts (Chapter 45).
opener
Value: Window object reference Read/Write
NN2 NN3 NN4 NN6 IE3/J1 IE3/J2 IE4 IE5 IE5.5
Compatibility
Many scripters make the mistake of thinking that a new browser window created
with the window.open()method has a child?parent relationship similar to the one
that frames have with their parents. That?s not the case at all. New browser win-dows,
once created, have a very slim link to the window from whence they came:
via the opener property. The purpose of the opener property is to provide scripts
in the new window with valid references back to the original window. For example,
the original window may contain some variable values or general-purpose functions
that a new window at this Web site wants to use. The original window may also On the CD-ROM

---

Some events you have to return false for, and some you have to return true for to indicate that you handled them. It's quite annoying.

While testing my Znippet yesterday, I discovered that onerror = null; does in fact work in Netscape.

Hmm, seems I got even more information than I was loooking for, while still missing the basic questions, which is more proper in that instance, return true; or return false;? I use return false; in the middle of a function where I just want tit to stop *now*, continue no further, etc... but I still get confused (as I am sure many others do as well?) by the significance of true vs. false.

Your pal, -doc-

we're are talking in the window.onerror() function's return values.

Basically and most of the times you won't write your own error handler you just want to discard the error, therefore you must "return true" to signal that you handled the error successfuly and you don't want that error box to appear.

if you 'return false' this will still popup the error handler of the browser, returning false here is the same as returning true or false when handling an <A> tag's onclick event.

the window.onerror = null; will work only in NetScape (as i tried it and saw it on their documentation page)

Well, I just looked at the CD that comes with the Javascript Bible 4th Edition. It had this nifty little page that seems to work quite nicely in NN4, NN6, IE5.5 concerning error dialogs and such.

I put a copy here: http://osiris.bugimus.com/gurus/lst16-10.htm

It looks like when errors are turned off, then "return true" is in order like lallous says.



[This message has been edited by Bugimus (edited 09-22-2001).]

Yah, I can dig that, it seems to make sense. Looking at the larger picture, I use "return false" when I want a function to simply stop processing whatever it's doing and exit. "Return true" is used mostly after window.status calls from the HREF! (heh) In the onerror function, stopping the processing of the doNothing() function is the same as returning true, at least in practical terms. I'm going to go do some google searches to see if I can get a good explanation of what the implications of true vs. false might be in the larger sense. I'll be back!

Your pal, -doc-