JavaScript default Error Handling disabled

The application I'm building with AW now includes almost 10,000 lines of JavaScript code. Needless to say, in testing and debugging the application I rely heavily on the IE "display a notification about every script error" option to identify bugs in my JavaScript code. I have found, however, that in numerous areas AW will disable the default Javascript error handling provided by the browser. This occurs most notably in any functions called from an AW button. I can enclose the code in those functions within try/catch blocks, but when I display an error in a catch I have no way of identifying the line number where the error occured. The default error handling in IE does display the line number of the error, which helps immensely in tracking down the cause of the error. Is there any way to prevent AW from turning off the default JavaScript error handling. Or is there a method to re-enable that default error handling within selected functions?

a few suggestions:

If your JavaScript gets to 10000 lines of code you're doing something wrong. Web Applications (running either over the web or on an intranet) shouldn't have that many lines of code. Period.

Secondly, I wouldn't rely on IE period. I use Firefox as it normally has better "judgment" in letting me know what the error was and have a better description for better debugging.

If you can't get around having 10000 lines of code CLIENT SIDE then I suggest breaking everything up in modules. for instance, if you're working with customers / suppliers then split their functions up into their own files.

AW helps a great deal in cutting down code, and if your code is 10000+ lines then you need to re-think your strategy. You can't have a web app with client side code being that huge, it will slow down things considerably on a PC that doesn't have the proper specs (as with client side code you rely heavily on their processing power instead of your server)

Anyway, hope you solve your problem

Well, it depends... I'd say 10k lines of js is ok for an intranet app.

Regarding debugging I think in the future I should provide two versions of aw.js - the 'production' and 'debug' version. The debug version will have all try {} catch(){} blocks removed and also have different levels of console output log. The build script then will then remove all AW.debug() calls from the 'production' version so that there will be no impact on performance. What do you think?

Alex,
Yes, I think the idea of production and debug versions would be very useful.

AcidRaZor,
The application has as many lines of code as it needs, after 25 years of writing software I don't write superfluous code. And of course it's in modules, I wouldn't try to put 10,000 lines of code in a single file. The application uses dozens of modules, and only loads the code that is needed for the particular screen being used. The application is a web-enabled replacement for a FoxPro-based desktop application, so virtually all of the functionality is client-side for performance reasons. And yes, the specs of the client PCs are critical, but since this is an intranet app we can control that. But the customer uses IE, so I have to rely on IE, I don't have a choice in that matter.