5

I have some tricky AJAX code on a form, and sometimes it will fail (don't ask why, I can't get around it). When this happens, I need to trap the error, reset a hidden field indicator, and submit the form naturally so that the user does not have an unpleasant experience. I planned on using window.onerror to do this, but it is never firing! I am using IE8 and all I have to worry about is the IE browser. Is there some gotcha to getting this event to work? Here's my code...

window.onerror = function() {
  alert("Error!");
  document.getElementById("hidAjax").value = "0";
  document.forms[0].submit();
}
Josh Stodola
  • 81,538
  • 47
  • 180
  • 227

3 Answers3

12

"A common problem that bites many developers occurs when their onerror handler is not called because they have script debugging enabled for Internet Explorer. This will be the case by default if you have installed the Microsoft Script Debugger or Microsoft Visual Studio 6.0® (specifically Visual InterDev 6.0™)—onerror handling is how these products launch their debugger. You can disable script debugging for a given instance of Internet Explorer on the Advanced tab of the Internet Options dialog box (note that checking the Disable script debugging setting will apply only to that instance of Internet Explorer):"

http://msdn.microsoft.com/en-us/library/ms976144.aspx

MikeEL
  • 674
  • 5
  • 13
  • Shoot, I didn't even think about that! So will my users have to have this setting disabled? – Josh Stodola Dec 16 '09 at 17:15
  • Yes, and since you can't depend on their environment, you will have to find some other way to do this. try/catch, would probably work out very well for you, with the catch block containing everything in your current onerror function. – MikeEL Dec 16 '09 at 17:46
  • just read your other comment... perhaps you could query your user base, and see if they have this set? if its only a small set of users in this case, you can set it as a stipulation that they need to turn it off. You should also be able to check if they have that set, and pop up an informative message for them on what to do to turn it off. – MikeEL Dec 16 '09 at 17:50
  • Crap. Time to write a program to wrap every function body with a try/catch. There's far too much code to do it manually. This ought to be fun! – Josh Stodola Dec 16 '09 at 18:55
2

try/catch also introduces an additional error object that only has the scope of the catch. In applications where performance matters, this is not a good idea.

Scott Marcus
  • 64,069
  • 6
  • 49
  • 71
0

Any reason not to just put a try/catch around the tricky code?

Annie
  • 6,621
  • 22
  • 27
  • 1
    There's a *ton* of code; it's split up into many functions across many files. – Josh Stodola Dec 16 '09 at 17:14
  • Because that is not the proper use for any exception handling paradigm. By simply wrapping code in an exception handler, you lose the ability to know exactly where your code is deficient and you write sloppier code as a result. Exception handling should only be used when you've done everything you could as a developer to avoid a runtime exception and the code may still fail. – Scott Marcus Sep 24 '14 at 14:23