Archive

Archive for September, 2009

JavaScript “finally” block is anti pattern.

September 21, 2009 4 comments

  I bet many of us hate debugging JavaScript code. The absence of strong-typing makes you pain when trying to figure out the error. So, you must employ the best patterns and practices of JavaScript and implement client code accurately. In some cases a debug tool becomes a useless tool.

  For instance, let’s review the following implementation:

function taskRunner(taskExecutor){
           try{
                    taskExecutor();
               }
       finally{ //debugger would navigate you to this line

                 //do some clean up

              }
       }

onload = function(){

          var task = function(){

               //process something

               //and then eventually facing exception

               return i+j;// - this line of code throws exception
             }

          taskRunner(task);
}

  The finally block of taskRunner function can be considered as anti-pattern. Whatever you do the debugger navigates you to finally block instead of real place of error at least for IE in this trivial sample. The one tool I know to figure out an error is a common sense. You have to search usages and analyze the code. Even if you manage not to use such constructions, it does not mean you to be safe. Nowadays, there are a lot JavaScript frameworks that probably use such constructions. I know one for sure. It’s the Ajax.net. The anti–pattern is exhibited in the Sys.net.XmlHttpExecutor.

  Once you have an error in one of your HttpRequest handlers, you will get into finally block immediately. How to figure out the error line? It’s good if you know what is going on, but what if you deal with legacy code and there is mix of Asp.Net update panels with ajax.net control and components(well-knowing name is extender). It is sad but your chances are low.