Picture this:

As if seeing something similar to that popping up in your console wasn’t bad enough, picture not being able to find an answer for the issue on Stack Overflow (you’d probably find a solution for this one, but I needed an example for this article😅).

In those situations you might not have any idea about where is the error originating from. Most of the files you see on the console are completely alien to you and you have no idea where to start tracking this issue.

That’s why today we’ll dive into how to read a stack trace in JavaScript.

TL;DR : Look for files that you recognize on the stack trace and follow the different calls from the bottom up. Check each of the files you recognize from your project for possible clues on what the error is about.

What is a stack trace?

A stack trace is an overview of all the called methods up to the point where an application crashed(you can also print the stack trace without a crash). It show the programmer which steps the program took from start of execution, all the way to the current state.

The stack trace has a few different parts that you should pay attention to, such as the error description, error source and called methods.

We’ll have a look at those on the paragraphs below.

The error description

At the very top of the stack trace you’ll find the error description. This description spells out what kind of error happened, in our example case it was the Uncaught ReferenceError: Hoi is not defined.

The stack trace doesn’t lie but sometimes with tricky errors, the description might just be a symptom and not the actual problem. Regardless of what it is, it can be a starting point for out debugging and with time, you’ll learn to distinguish between a symptom and the actual problem.

Now that we know what kind of error occurred we can go ahead and check where did it happen.

The source of the error

The first line on our stack trace will usually hold the file and line in which the error was thrown. In this case the error was thrown on the HelloWorld.vue file on line 87.

In this particular case, looking at that file would show us the issue, but you can have a situation like this:

• FileA imports a method from FileB
• That method in FileB uses a method from FileC to do some calculations then return the value

In that example, if FileB returns a null object to FileA and FileA tries to access a child on that null object, the error will be thrown in FileA, but the issue would be in FileB.

Reading the stack trace in that example would show you all the method calls and you could trace the problem back to FileB.

Finding the problem

As I previously mentioned, finding the source of your problem should start by looking at the files that are actually from your project.

Make sure that you read which error is being thrown and try to follow the trace. If the stack trace is too long, then just skim it for known files and check those. While you check those files, try to see if there is anything there that would trigger the error described at the top of the stack trace.

You can also look at the line numbers to know on which exact line was the method called.

If you would like to read more about stack traces, there is a great article on alligator that is quite interesting and clear.

Thanks for reading 👍

– Gásten Sauzande