Oh just let it crash

A have some quick advice about scripting languages.  It seems as programmers, we’re very untrusting of where data comes from and making assumptions about what it will be.  For example, if I had a function as such:

void RockCasbah(Casbah c);

I might want to make sure “c” was valid.  Like such:

if(c != null)
{
   c.Rock();
}

I think we’re trained to do this because if someone else tries to rock a null Casbah, we don’t want our whole application crashing.  In scripting languages I believe it’s a bit different.  You want to crash!  I’ve found myself checking for null quite often in my own script functions, which only I call and no one else.  Later on, I would discover a bug where something just doesn’t show up right because some function quietly exited without showing any errors.  My advice is to just let stuff crash sometimes; if something is never going to be null then don’t check it.  Just let there be a script error.  Your customers, unless they have script debugging enabled, won’t really be confused; they will probably see a “script error” icon in the browser status bar and become aware something isn’t quite right.  While developing, seeing an error popup will inform you early on that something is not running as expected, and you can debug into it then and there without having to wait for some random hard to reproduce bug to popup later on.

Mike