Often, error messages not only inform what the error was, but also where in code it happed and which execution path has lead to it. Read it carefully, analyze functions invoked, think what parameters may have cause them to fail look, for the origin of the problem.
Let’s have a look at the call stack, which is the most common thing developers see when coding and debugging. It’s useful because it shows a stack of functions that lead us to some place. Often it’s a line of code where an exception has occurred. We can then try to guess what happened and repeat some actions performed by system. Next, we can write tests which will automate this particular scenario and prevent it from happening in the future.
For a start have a very brief look at this simple code.
HTML:
<button onclick='updateTime()'>
Update time
</button>
JavaScript:
var getDateFromString = (dateString)=>{
if(dateString.length > 0){
return new Date(dateString);
}
else{
return new Date();
}
};
var getDateFromServer = () => {
return null;
}
function updateTime(){
var serverDate = getDateFromServer();
var newDate = getDateFromString(serverDate);
var toSet = newDate.getDate();
};
setTimeout(updateTime, 500);
First of the errors in the screenshot above will occur after just running the attached code in the browser.
Let’s inspect the call stack and try to find the origins of an error. What’s most important usually is at the top of the call stack – this is the place where the exception happened and where the program stopped it’s execution and informed us about the problem it had.
We can see that an engine couldn’t read a length property of some object and that the error happened in line number 9 of call_stack.html file. That limits our scope of search to the object with name dateString. In this simple example this object is a parameter of getDateFromString method. Where has it been called? By drilling down the call stack we can see that it was invoked by updateTime function, at line 23 in automatic call scheduled by programmer in setTimeout function.
Next, by looking at the code we can see that the parameter passed to the method was assigned a line before and it’s value comes from getDateFromServer function. It clearly returns null in this dummy example. But it could have happen that someone writing server code could return null in case of an error or that code handling server response could return null when server response was bad.
This way we have found the true source of our problem and can fix it either ourselves in correct place (the server response handling method) or report it to the backend developers.
I’ve attached the second call stack just to show that the code can be invoked from multiple places and why reading the whole message is just as important as what is shown at the top. In this example we can see that updating time was triggered by user. The onclick method in JavaScript/HTML is a simple way to invoke code when the button is clicked.