Cut it out and run

By on Mar 10, 2013 in eng | 3 comments

Share On GoogleShare On FacebookShare On Twitter

One of the big gaps between seasoned developers and the less experienced ones is the troubleshooting skill. Unlike any other knowledge, this kind of skill is difficult to teach and learn. Developers invest tons of hours to develop his or her own techniques in gathering information and seeing through details to find the root cause of the problem. Sometimes the problem is new or you don’t have enough knowledge in the tool or system that you are working on. This may lead to the dead end that you have run out of all the ideas. I have one simple technique I often use when I cannot think of anything else I can do.

Imagine that I am adding a small new feature to a web application. I have added a couple Backbone views and some new methods on the server side then refresh the page. Things are looking fine on Chrome but I get blank page on IE. Don’t worry if you don’t know Backbone.js framework. The example is simple enough for you to get the idea. A Backbone view looks something like the code below.

var StatusPanel = Backbone.View.extend({
	initialize : function(){
	render : function(){
	showStatus : function(status){
	showErrorMsg : function(error){

This problem seems to be about browser dependent things. I am working on IE which doesn’t have debugger or browser console to look at more accurate information of the error like I can do in Chrome. The error line number of IE is useless (as it normally is) in this case. I then review my new code over and over and found nothing suspicious. I also don’t have any specific error string to search for more information on internet. There may be some other clever ways to scope down the problematic area but I just can’t think of anything with my current knowledge of the tool. I am stuck.

I have no choice but to use the primitive and time consuming technique of adding alert message to see the last line that get executed. If that still don’t give me any clue then I will turn to the last method; making some guesses to cut out some parts of the code and run the page again.

The idea is to scope down the problematic area. If cutting a part of code makes the result or the nature of the error change then I know that the part is a contributing factor to the problem. In my case, I have a couple new views; MainView, SearchPabnel, StatusPanel and ResultTable. If I get rid of the ResultTable and the nature of the error doesn’t change (the page still show blank screen) then the view may not have anything to do with this problem.

It turns out if I cut out the StatusPanel (along with the code that make use of the panel in the initial load of the page) then the page will be able to render other views on screen. The page is not fully functional but now I know that the problematic part is the code that initializing this view. I could then compare the good view and the bad view to see what might cause this browser dependent issue. I finally notice an extra comma after the end of the showErrorMsg() method. I try removing the comma and put the StatusPanel back to the page and run it again. The whole page suddenly works just fine.

You can see that the method mostly relies on a hunch and educated guess. It doesn’t look quite smart but sometime it is the best you can do. You may finally find new ways or tools that could help you identify the problem faster once you learn about the root cause. In our case, now I get more specific string to search for. The “extra comma” or “trailing comma” and “JavaScript on IE” should get me more information.

I remember being very frustrated with this problem when I first experienced it. It took me quite some time to notice the extra comma. I just came across it again last week when I making some changes on the existing Backbone view. This time I immediately looked for the extra comma in the new code when I saw that the problem only occurred on IE.

You may need to apply some trick to the code like replacing the suspicious part with a simple stub component in case you can’t totally get rid of the part. Sometimes you even have to make a wild guess on what might cause the problem. I once solved a JQuery UI problem by replacing <div name =”msg”/ > with <div name =”msg”> </div>. I really don’t have an idea on why the first format break the JQuery Tab . I just tried replacing it with an equivalent code and it worked.

The underlying idea is to remove/replace/reorder things in the code to see the effect and scope down the problematic area. Try it as the last method when you can’t think of anything else to do.


  1. JoeSB

    March 12, 2013

    Ha ha ha. As soon as you said your code didn’t work in IE, I immediately go back up and look for that extra comma. It bit me bad many times.

    The reason your ‘div’ case doesn’t work is because HTML is not XML. HTML does not have a concept of self-closing tag. When you wrote (replacing braces with angle bracket) {div name=”msg” /}, what the browser sees is {div name=”msg” /=”” }. That is, it just sees you starting DIV tag with attribute named “/” with empty string value. And you still have un-closed DIV tag.

    P.S. Can you not require email address for posting? It’s kinda suspicious for me.
    P.P.S. The text color for text input area is way too white.

  2. JoeSB

    March 12, 2013

    Oh, and “empty element tags”, such as IMG, META, HR, etc., are actually supposed to be written as simply {img} with no closing slash.

  3. chatchai

    March 12, 2013

    LOL , a lot of time have to be spent to make things work on IE.
    Thanks very much for the info of self-closing tag, that is very new to me.
    I will look if there is any config about the email for commenting.

Submit a Comment

Your email address will not be published. Required fields are marked *