Wacky Uncle Billy’s Development Blog

Debugging JavaScript is hard enough - but it is especially annoying when you have spent a good amount of time tracking down a bug and it turns out to be a type error (i.e., your function expected a Boolean true but got a String “true”). Perhaps your value was implicitly cast to another type by some operation, or maybe you forgot to pass the right arguments to a method. In a statically-typed, compiled language (such as AS3 or Java), you would find out about bad arguments during compile time - and you’d probably get a nice, descriptive error message of what was going on.  Not so with JavaScript - in fact, because it is loosely and dynamically typed, you may not find out about your bad argument until you waste an hour or two tracking down a bug.

To avoid this sort of thing, you can throw your own errors when a method or constructor doesn’t get what it expects. The pattern is easy to get the hang of.  The very first time you get one of these errors, you will feel good about all this extra typing. 

/**
* A function that creates a new barf bag.
* @param {Boolean} zip          Whether this bag has a zipper or not.
* @param {String} bagType     Valid types: "paper"|"plastic"
* @param {String} vomitType  Valid types: "chunky"|"bile"|"watery"
*/
var VomitBag = function(zip, bagType, vomitType) {
   /* validate arguments */
   if(typeof zip != "boolean") throw new Error("VomitBag: expected zip to be Boolean");
   if(typeof bagType != "string" || !(/^paper$|^plastic$/.test(bagType)) throw new Error("VomitBag: expected bagType to be String and to be either 'paper' or 'plastic'");
   if(typeof vomitType != "string" || !(/^chunky$|^bile$|^watery$/.test(vomitType)) throw new Error("VomitBag: expected vomitType to be String and to be 'chunky', 'bile', or 'watery'");

   /* some code... */
}

This technique is not at all new to JavaScript. For example, Marijn Haverbeke talks about it briefly during a good writeup about error handling in Eloquent JavaScript: Error Handling - Eloquent JavaScript (that whole site is worth reading).

Comments(0)

I’ve stumbled across a bug in Opera 9.27 (which I dutifully reported).  Basically, if you disable a form element and use the DOM2 dispatchEvent method on the element to simulate a click, the element fires the event.  Since the element is disabled, it should not fire any click event handlers - this is the behavior in Firefox and Safari.   Here’s the html I used to prove it:

Opera disabled form element / dispatchEvent test

Comments(0)

I’m an encapsulation fanatic.  I love to write code where data is protected from view and unavailable for mischief.  I like the ability to react to changes to the internal state of a function. Also, the thought of something accessing and re-writing a method or variable on another class instance scares me, and I’d rather just not let it happen.  A ton of my code ends up looking like this:

var Cookie = function() {
   var chips = {};
   this.addChip = function(type) {
      chips[type]++;
      bakeCookie();
   }
}

On the other hand, there are quite a few times when I’m writing JavaScript that I wonder when I should be worrying about efficiency.  It’s an obvious fact that using prototype methods can increase efficiency by reducing the amount of memory and processing required.  I’ve always assumed (from doing very short, non-scientific tests in a browser) that this technique pays off only when using many instances of a particular object.

var Cookie = function() {
   this.chips = {};
}
Cookie.prototype.addChip = function(type) {
   this.chips[type]++;
}

You might as well not even have the addChip method at this point. Anybody could come along and change chips - hell, they could turn it into a number or something.

Without the ability to maintain privacy, you won’t ever know when your properties change (in case you want to do something when one changes). Without privacy, you can’t hide your implementation details and provide a clean interface (in case you need to re-write the guts of your function) without a guarantee that nobody has latched onto one of the properties or methods you don’t care about anymore.

This is one of the most frustrating things about JavaScript for me. For performance, we are forced to make a decision wherein we must sacrifice privacy. Personally, I don’t use prototype methods all that much - until I know that a class I’m using will be instantiated many, many times, it just doesn’t make sense to me to lose all the benefits of privacy. Performance be damned - hell, from what I heard, you are supposed to optimize as a last resort, anyway.

I’d love to hear what other people think, though.

Comments(0)

One of the neat things I learned at the last No Fluff Just Stuff conference I went to was from one of Neal Ford’s Productive Programmer seminars.   Script everything.  I’ve been using this as my mantra lately.  Why should I do steps a, b, c, d, e, f, and g again, even if I only do the task once a day or even once a week?  I’m still looking for a script to help me remember stuff, like car keys and feeding the cats.  

Comments(0)