Comments on: The Art of Throwing Errors in JavaScript http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript Cleaning up the web with Ajax Thu, 09 Feb 2012 06:55:33 +0000 hourly 1 http://wordpress.org/?v=3.2 By: BertrandLeRoy http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271831 BertrandLeRoy Fri, 06 Mar 2009 05:22:50 +0000 http://ajaxian.com/?p=6177#comment-271831 @braddunbar: no problem. I apologize myself for being a little rude. @braddunbar: no problem. I apologize myself for being a little rude.

]]> By: braddunbar http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271829 braddunbar Fri, 06 Mar 2009 02:06:22 +0000 http://ajaxian.com/?p=6177#comment-271829 @BertrandLeRoy I did not know that the error checking was taken out of the production version. Thanks for pointing that out, and my apologies for any misrepresentation I gave. @BertrandLeRoy I did not know that the error checking was taken out of the production version. Thanks for pointing that out, and my apologies for any misrepresentation I gave.

]]> By: BertrandLeRoy http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271827 BertrandLeRoy Thu, 05 Mar 2009 23:15:02 +0000 http://ajaxian.com/?p=6177#comment-271827 @braddunbar: please check before you make such uninformed statements. Microsoft Ajax, like most JavaScript libraries, comes in two flavors: minimized/release and debug. The error checking code is very extensive but is only present in the debug version, as it should. The release/minimized version has no error checking except on errors that might make sense for the end user and that are not developer errors (network timeouts and such). As Microsoft Ajax has shown since the first version, it is entirely possible to provide meaningful error messages and stack traces to application developers without compromising performance, by only instrumenting the debug version. @braddunbar: please check before you make such uninformed statements. Microsoft Ajax, like most JavaScript libraries, comes in two flavors: minimized/release and debug. The error checking code is very extensive but is only present in the debug version, as it should. The release/minimized version has no error checking except on errors that might make sense for the end user and that are not developer errors (network timeouts and such).
As Microsoft Ajax has shown since the first version, it is entirely possible to provide meaningful error messages and stack traces to application developers without compromising performance, by only instrumenting the debug version.

]]> By: shadedecho http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271826 shadedecho Thu, 05 Mar 2009 22:42:40 +0000 http://ajaxian.com/?p=6177#comment-271826 I think at least some JS widgets/modules/libraries could benefit from explicit "error callback" functionalities, where the user of a library can explicity subscribe to know about certain internal (non-api-abuse related) and unforseeable events. For instance, I have an XHR clone library (called flXHR http://flxhr.flensed.com/ ) which exposes an "onerror" callback handler which will send all errors to that callback if defined. Otherwise, it throws them as javascript errors. I think this is the best of both worlds. And it's really not that much extra code to do so. I think at least some JS widgets/modules/libraries could benefit from explicit “error callback” functionalities, where the user of a library can explicity subscribe to know about certain internal (non-api-abuse related) and unforseeable events. For instance, I have an XHR clone library (called flXHR http://flxhr.flensed.com/ ) which exposes an “onerror” callback handler which will send all errors to that callback if defined. Otherwise, it throws them as javascript errors. I think this is the best of both worlds. And it’s really not that much extra code to do so.

]]> By: fzammetti http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271825 fzammetti Thu, 05 Mar 2009 21:52:11 +0000 http://ajaxian.com/?p=6177#comment-271825 I agree with kumar303 here, and I'd go a step further and say a good API should intentionally minimize the number of times you need to consult documentation. With a good API, I can give you a simple list of method signatures, including exceptions that can be thrown, and that will largely be all the documentation you usually need. The method names reflect their function, the argument names reflect what they are and the exception information tells you what can typically go wrong (it's all a little trickier in JavaScript of course, as dynamic as it is, but still). I agree with kumar303 here, and I’d go a step further and say a good API should intentionally minimize the number of times you need to consult documentation. With a good API, I can give you a simple list of method signatures, including exceptions that can be thrown, and that will largely be all the documentation you usually need. The method names reflect their function, the argument names reflect what they are and the exception information tells you what can typically go wrong (it’s all a little trickier in JavaScript of course, as dynamic as it is, but still).

]]> By: Spocke http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271824 Spocke Thu, 05 Mar 2009 21:36:36 +0000 http://ajaxian.com/?p=6177#comment-271824 The main reason why I don't use exceptions in JS is the code size. Adding thousands of throws takes lots of space. But I guess one could have two versions of their scripts one with error checking enabled that could be used while developing then another production version that doesn't do all the error checking. One could use a JS preprocessor to remove that error checking logic. I've blogged about such a thing a few days ago. http://blog.moxiecode.com/2009/03/02/javascript-build-process-using-ant/ The main reason why I don’t use exceptions in JS is the code size. Adding thousands of throws takes lots of space. But I guess one could have two versions of their scripts one with error checking enabled that could be used while developing then another production version that doesn’t do all the error checking.

One could use a JS preprocessor to remove that error checking logic. I’ve blogged about such a thing a few days ago. http://blog.moxiecode.com/2009/03/02/javascript-build-process-using-ant/

]]> By: kumar303 http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271823 kumar303 Thu, 05 Mar 2009 21:28:02 +0000 http://ajaxian.com/?p=6177#comment-271823 "null has no attribute named render" Do I need to say anything more? Yes, throwing exceptions is the only way to ensure proper inputs. People shouldn't have to always read documentation to figure out how something works. I don't see how it introduces huge performance penalties as long as you design your functions right. “null has no attribute named render”

Do I need to say anything more? Yes, throwing exceptions is the only way to ensure proper inputs. People shouldn’t have to always read documentation to figure out how something works. I don’t see how it introduces huge performance penalties as long as you design your functions right.

]]> By: Nosredna http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271822 Nosredna Thu, 05 Mar 2009 20:38:13 +0000 http://ajaxian.com/?p=6177#comment-271822 fzammetti, Anything calculation bound, I've NEVER seen IE6 do well on. But I'm willing to believe that there are real world problems where it does happen. There are many potential bottlenecks in the world of browsers. Everyone seems to be doing something a bit different. Just look at the wars between benchmarks. fzammetti,

Anything calculation bound, I’ve NEVER seen IE6 do well on. But I’m willing to believe that there are real world problems where it does happen. There are many potential bottlenecks in the world of browsers. Everyone seems to be doing something a bit different. Just look at the wars between benchmarks.

]]> By: fzammetti http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271821 fzammetti Thu, 05 Mar 2009 20:25:33 +0000 http://ajaxian.com/?p=6177#comment-271821 @Nosredna: HAHA, I like that! - Ironically, and I've said this on numerous occasions: I've actually seen BETTER performance in many cases with IE6 than IE7, FF3 or Opera9 (I don't use Chrome, or Safari so can't really compare them). Don't get me wrong: I have *NO* trouble believing that is due to factors other than the browser itself, i.e., configuration, network, whatever, but I've seen it time and again in direct contradiction to what most of the "experts" always claim. - Still, great line :) @Nosredna: HAHA, I like that!
-
Ironically, and I’ve said this on numerous occasions: I’ve actually seen BETTER performance in many cases with IE6 than IE7, FF3 or Opera9 (I don’t use Chrome, or Safari so can’t really compare them). Don’t get me wrong: I have *NO* trouble believing that is due to factors other than the browser itself, i.e., configuration, network, whatever, but I’ve seen it time and again in direct contradiction to what most of the “experts” always claim.
-
Still, great line :)

]]> By: Nosredna http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271820 Nosredna Thu, 05 Mar 2009 19:54:12 +0000 http://ajaxian.com/?p=6177#comment-271820 @fzammetti, The speed improvements to JavaScript are great. It's just that our grandmother is in the room (IE6), and she keeps interrupting the conversation by saying, "what, what, what?" @fzammetti,

The speed improvements to JavaScript are great. It’s just that our grandmother is in the room (IE6), and she keeps interrupting the conversation by saying, “what, what, what?”

]]> By: fzammetti http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271818 fzammetti Thu, 05 Mar 2009 19:20:26 +0000 http://ajaxian.com/?p=6177#comment-271818 Performance is of course a valid consideration here. But, for those of us that have been doing Java development for a long time you can recognize that we're at a stage with JavaScript where we were with Java a few years ago: there's some really good ideas that you shy away from on the grounds of performance. I think this is one of them. - For example, it used to be common knowledge that you should using StringBuffer in Java as opposed to simple string concats. With modern VMs though, this isn't much of a consideration because they optimize that sort of thing behind the scenes anyway. In light of that, code readability becomes the bigger concern (putting aside the debate about whether string concats actually are more readable or not!) - Similarly, we're starting to get super-fast JS engines and so at some point we have to start thinking more about readability and maintainability of code than performance, at least in some instances (you should *never* simply forget performance of course, just that sometimes it's OK to put it on the back burner in favor of other considerations). It's of course valid to debate whether this throwing errors idea is good or not in the first place, but if you think it is as I do then at some point the consideration of writing "better" code takes precedence over performance. Performance is of course a valid consideration here. But, for those of us that have been doing Java development for a long time you can recognize that we’re at a stage with JavaScript where we were with Java a few years ago: there’s some really good ideas that you shy away from on the grounds of performance. I think this is one of them.
-
For example, it used to be common knowledge that you should using StringBuffer in Java as opposed to simple string concats. With modern VMs though, this isn’t much of a consideration because they optimize that sort of thing behind the scenes anyway. In light of that, code readability becomes the bigger concern (putting aside the debate about whether string concats actually are more readable or not!)
-
Similarly, we’re starting to get super-fast JS engines and so at some point we have to start thinking more about readability and maintainability of code than performance, at least in some instances (you should *never* simply forget performance of course, just that sometimes it’s OK to put it on the back burner in favor of other considerations). It’s of course valid to debate whether this throwing errors idea is good or not in the first place, but if you think it is as I do then at some point the consideration of writing “better” code takes precedence over performance.

]]> By: CaptainN http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271813 CaptainN Thu, 05 Mar 2009 16:42:55 +0000 http://ajaxian.com/?p=6177#comment-271813 I've gone back and forth on whether to do this kind of error checking in SwfHTML (http://code.google.com/p/unfocus-history-keeper/source/browse/trunk/javascript/SwfHTML.js ). I've become pretty comfortable in this instance. The errors have saved me a bit of work a number of times, by tracing an incorrect setting to Firebug, where if I hadn't used error checking I would have let those settings fail silently. In this example though, there are not a lot of performance issues, since this is a pretty basic object in scope - but still, I do find throwing errors to be a tremendous time saver, especially when you have to utilize some library or bit of code that you haven't used in a while. I’ve gone back and forth on whether to do this kind of error checking in SwfHTML (http://code.google.com/p/unfocus-history-keeper/source/browse/trunk/javascript/SwfHTML.js ). I’ve become pretty comfortable in this instance. The errors have saved me a bit of work a number of times, by tracing an incorrect setting to Firebug, where if I hadn’t used error checking I would have let those settings fail silently. In this example though, there are not a lot of performance issues, since this is a pretty basic object in scope – but still, I do find throwing errors to be a tremendous time saver, especially when you have to utilize some library or bit of code that you haven’t used in a while.

]]> By: Nosredna http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271812 Nosredna Thu, 05 Mar 2009 16:41:08 +0000 http://ajaxian.com/?p=6177#comment-271812 >>Especially with javascript which still has a bad reputation… It does? >>Especially with javascript which still has a bad reputation…

It does?

]]> By: neonskimmer http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271811 neonskimmer Thu, 05 Mar 2009 16:14:58 +0000 http://ajaxian.com/?p=6177#comment-271811 There's a danger in seeing the frameworks as a kind of magic box that does things for you that you don't understand. I'm all for not reinventing the wheel, but it's definitely important as a programmer to have a modicum of understanding of the tools you are using - at least to your personal capacity if you are 'not quite there yet'. There’s a danger in seeing the frameworks as a kind of magic box that does things for you that you don’t understand.

I’m all for not reinventing the wheel, but it’s definitely important as a programmer to have a modicum of understanding of the tools you are using – at least to your personal capacity if you are ‘not quite there yet’.

]]> By: ywg http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271809 ywg Thu, 05 Mar 2009 16:12:17 +0000 http://ajaxian.com/?p=6177#comment-271809 If you work alone or with a "standard" library, maybe. But in a team project, this could make the difference between hard to exploit (or even rejected) code, and good work. Especially with javascript which still has a bad reputation... Delivering irreproachable code and taking your co-workers by the hand is sometimes necessary. If you work alone or with a “standard” library, maybe.
But in a team project, this could make the difference between hard to exploit (or even rejected) code, and good work.
Especially with javascript which still has a bad reputation… Delivering irreproachable code and taking your co-workers by the hand is sometimes necessary.

]]> By: daitro http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271808 daitro Thu, 05 Mar 2009 15:57:03 +0000 http://ajaxian.com/?p=6177#comment-271808 @ywg I still hardly see how that would be any useful, with firebug and jslint you are pretty much covered. Any doubts? Check the docs. Simple as that. If you need a library that checks your stupidity you can try ajax.net @ywg

I still hardly see how that would be any useful, with firebug and jslint you are pretty much covered. Any doubts? Check the docs. Simple as that. If you need a library that checks your stupidity you can try ajax.net

]]> By: WillPeavy http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271806 WillPeavy Thu, 05 Mar 2009 15:31:59 +0000 http://ajaxian.com/?p=6177#comment-271806 Throwing errors would bloat libraries, and divert library developers' time from projects that I think would be more useful. I would rather not have it. Throwing errors would bloat libraries, and divert library developers’ time from projects that I think would be more useful. I would rather not have it.

]]> By: ywg http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271805 ywg Thu, 05 Mar 2009 15:13:06 +0000 http://ajaxian.com/?p=6177#comment-271805 @braddunbar, daitro What you need is to pass a param "-debug" to your build process, and flag all your debug/throw instruction. This way you can build one clean file for maintenance, and a minified one for production. @braddunbar, daitro

What you need is to pass a param “-debug” to your build process, and flag all your debug/throw instruction.

This way you can build one clean file for maintenance, and a minified one for production.

]]> By: Nosredna http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271804 Nosredna Thu, 05 Mar 2009 15:10:02 +0000 http://ajaxian.com/?p=6177#comment-271804 Until JavaScript is faster in all browsers (including IE), I don't want the JS libraries doing any extra checking. I want them to go fast. Java's VM is now pretty fast, so it can afford to do sanity checking in libraries. However, I'd gladly accept two versions of the library--a debug and a release. Until JavaScript is faster in all browsers (including IE), I don’t want the JS libraries doing any extra checking. I want them to go fast. Java’s VM is now pretty fast, so it can afford to do sanity checking in libraries.

However, I’d gladly accept two versions of the library–a debug and a release.

]]> By: Nosredna http://ajaxian.com/archives/the-art-of-throwing-errors-in-javascript/comment-page-1#comment-271802 Nosredna Thu, 05 Mar 2009 15:04:19 +0000 http://ajaxian.com/?p=6177#comment-271802 "You can throw an by using the throw operator" syntax error “You can throw an by using the throw operator”

syntax error

]]>